Re: Determine if a value is Callable/Constructible

[Yehuda Katz]

On Mon, Mar 30, 2015 at 8:54 AM, Domenic Denicola  wrote:

> From: Kevin Smith [mailto:zenpars...@gmail.com]
>
> > I'd imagine that you'd re-spec [[Call]] for class constructors to
> basically do `this[Symbol.call](...args)` instead of just throw.  It would
> therefore only have an effect within class constructors.  Is that still
> weird?
>
> At least it's explicable, but it's still pretty weird I think. I mean, we
> don't specify [[Construct]] by saying that it does `new
> this.prototype.constructor(...args)` or similar. The asymmetry is jarring.
>
> And it's weird to have this symbol with such a generic name that doesn't
> work for anything except class syntax. I'd expect symbols to be for
> re-usable protocols... that's fuzzy intuition though, I admit, and might be
> contradicted by existing examples.
>

I like the idea of a special syntactic form a lot. One of the nice things
about `constructor` is that it's easy to explain "you [[Construct]] with
the constructor". We can't use `call` similarly any more, but I totally
agree something like it would be pretty nice.

On the flip side, it's not *entirely* clear that allowing people to
override [[Call]] on an existing function is a no-go. Changing the `typeof`
via installing a symbol definitely seems like bad juju though.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Determine if a value is Callable/Constructible

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325

On Mon, Mar 30, 2015 at 8:09 AM, Domenic Denicola  wrote:

> I don’t think [Symbol.call] is a very good mechanism. A new syntactic form
> would make more sense.
>
> It doesn’t seem right that you should have to introduce an observable
> prototype property just to get [[Call]] behavior. (Or a constructor
> property, if you change the syntax to `static [Symbol.call]() { … }`.)
>

A new syntactic form sounds good to me :)


>
> And it raises the question of what happens when I add a [Symbol.call]
> property to other objects. What does it even mean? If I do `var obj = {
> prototype: { [Symbol.call]() { console.log("foo"); } } }`, can I now call
> `obj()`? Is `typeof obj === "function"`? Very strange stuff. Presumably not
> very VM-friendly either, but that's just a guess.
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Determine if a value is Callable/Constructible

[Yehuda Katz]

On Mon, Mar 30, 2015 at 5:36 AM, Caitlin Potter 
wrote:

> >On Mar 30, 2015, at 1:49 AM, Allen Wirfs-Brock 
> wrote:
>
> >There is no intrinsic reason why we needed to mandate that class
> constructors should throw when called.  We even provided a simple and
> straight forward way
> >(new.target===undefined) that a ES constructor body can use to determine
> whether it was called or new’ed.
>
> I don’t think it’s great to have branches in a constructor dealing with
> this — it’s not super-obvious reading the code what it means (so it’s
> another thing to train people to understand).
>

That's exactly my position. The co-mingling of [[Construct]] and [[Call]]
in a single function was a side-effect of having all-singing, all-dancing
functions. The nice thing about ES6 is that we got dedicated syntax for
classes and callbacks. Just because we *can* make constructor functions
serve double-duty via a reflective mechanism doesn't mean that's the right
thing to do.


> A better way (which I think has been suggested by someone already in a
> different thread), would be to have a separate “magic” method to provide
> `call` code.
>
> ```js
> class Buffer {
>   constructor(…a) {
> // …
>   }
>
>   factory(…a) { // [@@factory](), __factory__(), whatever
> return new Buffer(…a);
> // Or whatever else one might wish to do in a factory method
>   }
> }
> ```
>

That was the proposal I made that Allen alluded to:

```js
class Buffer {
  constructor(…a) {
// …
  }

  [Symbol.call](a) {
if (typeof a === 'string') {
  return Buffer.fromString(a);
}

return new Buffer(…arguments);
  }
}
```


>
> But, I think the factory problem is solved well enough with static methods
>
> ```js
> class Buffer {
>   constructor(…a) {
> this.initialize(…a);
>   }
>
>   // Much easier to understand these, compared with Buffer(someBuffer) or
> Buffer(someArray) etc
>   static withBuffer(buffer) { assert(Buffer.isBuffer(buffer)); return new
> Buffer(buffer); }
>   static withArray(array) { assert(Array.isArray(array)); return new
> Buffer(array); }
>   static withSize(size) { assert(IsUInt(size)); return new Buffer(size); }
>   static fromString(str, encoding = “utf8") { assert(IsString(str) &&
> IsString(encoding)); return new Buffer(str, encoding); }
>
>   initialize(…a) {
> switch (a.length) {
>   case 1:
> if (IsUInt(a[0])) return allocateBufferOfSize(this, a[0]);
> else if (Array.isArray(a[0]) return allocateBufferFromArray(this,
> a[0]);
> else if (Buffer.isBuffer(a[0]) return allocateCopyOfBuffer(this,
> a[0]);
> else if (IsString(a[0]) { /* fall through */ }
> else ThrowTypeError(“Function called with incorrect arguments!");
>   case 2:
> if (IsUndefined(a[1]) a[1] = “utf8”;
> if (IsString(a[0] && IsString(a[1]))  return
> allocateBufferFromString(this, a[0], a[1]);
>   default:
> ThrowTypeError(“Function called with incorrect arguments!");
> }
>   }
> }
> ```
>

I agree that static methods are sufficient, but I also agree that it would
be nice to be able to describe existing built-in APIs in terms of classes.
That doesn't, however, mean that we need to force both use-cases into a
single function called *constructor*.

I feel strongly that this:

```js
class Buffer {
  constructor(from) {
// switch on Number, isArray, or Buffer
  }

  [Symbol.call](from, encoding='utf8') {
if (typeof from === 'string') {
  return Buffer.fromString(from, encoding);
}

return new Buffer(from);
  }
}
```

is clearer than:

```js
class Buffer {
  constructor(from, encoding='utf8') {
if (!new.target) {
  if (typeof from === 'string') {
return Buffer.fromString(from, encoding);
  }
}

// switch on Number, isArray, or Buffer
  }
}
```

For one thing, it requires the reader to know that `new.target` is being
used to determine whether the constructor was called with `new`. While it
certainly is expressive enough, it's an unusual reflective operation that
doesn't exactly say what you mean. For another, putting two uses into a
single method and separating them by an `if` is quite often a hint that you
want to break things up into two methods. I think that's the case here.

One of the nice things about the `[Symbol.call]` method is that a reader of
the class can determine at a glance whether it handles [[Call]], and not
have to scan the constructor to see if (and how!) `new.target` is used. And
since `new.target` can also be used for other usages, a reader unfamiliar
with the pattern might not even have a good query to Google (searching
"what is new.target for in JavaScript", even if that works at all, might
likely bring up a bunch of articles about implementing base classes).

>I think we should just drop that throws when called feature of class
> constructors..
> >
> >(The restriction was added to future proof for the possibility of
> inventing some other way to provide a class with distinct new/call

Re: Determine if a value is Callable/Constructible

[Yehuda Katz]

On Sun, Mar 29, 2015 at 10:49 PM, Allen Wirfs-Brock 
wrote:

>
> > On Mar 29, 2015, at 11:51 PM, Caitlin Potter 
> wrote:
> >
> > ...
> >
> > Reflect.isConstructor(fn) -> true if Class constructor, generator, or
> legacy (and non-builtin) function syntactic form
> > Reflect.isCallable(fn) -> true for pretty much any function, except for
> class constructors and a few builtins
>
> I’ve already seen another situation (node’s Buffer) where code could be
> simplified by using a ES6 class definition but where that is prevented
> because a class constructor throws when called.
>
> Just to clarify something.  Class constructors actually are “callable”.
> You can observe this by the fact that Proxy allows you to install an
> “apply” handler (the reification of the [[[Call]] internal method) on a
> class constructor.   The the fact that an object can be [[Call]]’ed is
> already reflected  by the typeof operator.  Class constructors throw when
> called because at the last minute we choose to make their [[Call]] do an
> explicit throw not because they aren’t callable.
>
> There is no intrinsic reason why we needed to mandate that class
> constructors should throw when called.  We even provided a simple and
> straight forward way (new.target===undefined) that a ES constructor body
> can use to determine whether it was called or new’ed.
>
> I think we should just drop that throws when called feature of class
> constructors..


> (The restriction was added to future proof for the possibility of
> inventing some other way to provide a class with distinct new/call
> behavior. I don’t think we need nor can afford to wait for the invention of
> a new mechanism which will inevitably be more complex than new.target,
> which we already have.)
>

I don't think this is an accurate representation of the discussion we had.


>
> Allen
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: classes and enumerability

[Yehuda Katz]

Worth noting: DOM "classes" won't be the only objects a JavaScript user
interacts with that have enumerable methods. Virtually 100% of class
libraries in JavaScript, including ones created after ES5, create classes
with enumerable methods.

I don't think that this change has a prayer of making enumerable methods
feel "weird" in JavaScript any time soon.

Yehuda Katz
(ph) 718.877.1325

On Fri, Jan 30, 2015 at 8:58 PM, Brendan Eich  wrote:

> Andrea Giammarchi wrote:
>
>> Do we agree this class decision was a good one? Perfect, then let's move
>> on to another thread and discuss how things could be better from "both
>> worlds" point of view in the future.
>>
>
> I'm not sure why you replied to me, since I (and everyone on TC39) has
> agreed to make the decision for class methods to be non-enumerable, so we
> must all agree that decision was a good one! :-P
>
> Probably you're replying to Anne, indirectly.
>
>
> /be
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: classes and enumerability

[Yehuda Katz]

On Thu, Jan 29, 2015 at 6:43 PM, Boris Zbarsky  wrote:

> On 1/29/15 9:41 PM, Yehuda Katz wrote:
>
>> I've personally written a lot of code that enumerates over the
>> properties of an element or other DOM object for some reason or other. I
>> strongly suspect that making existing WebIDL attributes non-enumerable
>> would not be web-compatible (nor, or even in the somewhat distant future).
>>
>
> I agree for elements, and probably all nodes.
>
> On the other hand, I'm fairly sure that no one depends FormData, say...


Right, but that's precisely your point about API predictability. We
shouldn't mix and match based on whether we can get away with it, or nobody
will have any idea what to expect.


>
>
>  I would agree that (2) isn't a good option, and I doubt (3) is
>> web-compatible ... :tears:
>>
>
> That's about where I am... and those three options were in fact discussed
> on this list before.
>
> Ah, well.
>
> -Boris
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: classes and enumerability

[Yehuda Katz]

On Thu, Jan 29, 2015 at 5:51 PM, Boris Zbarsky  wrote:

> On 1/29/15 5:43 PM, Allen Wirfs-Brock wrote:
>
>> My sense, from the informal discussions about this at the TC39 meeting,
>> is that most of us would hope that new WebIDL abstractions follow the ES6
>> class conventions and that existing WebIDL, because of legacy constrants
>> abstraction are likely not to migrate to the ES6 class conventions.
>>
>
> OK.  Just so we're clear, there are well north of 500 existing Web IDL
> interfaces defined in the web platform.  It will be a while, if ever,
> before the "new" ones get anywhere close to that.
>

I've personally written a lot of code that enumerates over the properties
of an element or other DOM object for some reason or other. I strongly
suspect that making existing WebIDL attributes non-enumerable would not be
web-compatible (nor, or even in the somewhat distant future).


> So what that approach (assuming none of the existing things are migrated)
> does is basically doom the web platform to always having behavior that
> authors can't predict.  I doubt I can actually get on board with that
> course of action  :(


I agree that that sounds bad. The options seem to be:

   1. DOM objects don't behave like classes defined with inline methods
   2. Only new DOM objects behave like classes defined with inline methods
   3. Change all DOM objects to behave that way, if we can do so without
   breaking the web

I would agree that (2) isn't a good option, and I doubt (3) is
web-compatible ... :tears:


>
>
>  Syntactically, in WebIDL, you would presumably need an attribute or
>> something to indicate which set of conventions to use for any particular
>> interface.
>>
>
> Sure.  I'm worried about the goals, not the syntax; the syntax is trivial.
>
> -Boris
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: classes and enumerability

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325

On Thu, Jan 29, 2015 at 1:46 PM, Boris Zbarsky  wrote:

> On 1/29/15 4:36 PM, Yehuda Katz wrote:
>
>> Are you asking what to do about the fact that existing WebIDL "classes"
>> produce enumerable properties that probably can't be made non-enumerable
>> without breaking the web?
>>
>
> I think the following things need to be decided:
>
> 1)  What should the behavior be for WebIDL objects going forward?
> 2)  If the going forward behavior is to have properties non-enumerable,
> should we try to migrate some subset of the existing Web IDL
> objects to the new behavior?
>
> I'm pretty sure we can't migrate all existing things, at least without
> breaking someone somewhere, but I suspect we can migrate many of them, if
> we decide it's actually worthwhile.
>

To be completely clear, there's nothing that requires DOM to define its
objects as using precisely the semantics of ES6 "classes", and indeed,
nothing that stops an ES6 class from having enumerable methods:

class Simple {
}

// enumerable

Simple.prototype.method = function() {}

If I understand you correctly, what you're saying is that you would *like* DOM
"classes" to look similar to a normally defined ES6 class.

That is a reasonable desire (and I would love to continue discussing it),
but it's not something that's squarely in TC39's wheelhouse (since DOM
classes aren't defined using ECMAScript class syntax, which is all that
this decision directly affects).


>
> I'd be pretty interested in knowing what other implemntors think here,
> because if we make some decision on #1 I'd rather not have people continue
> to ship whatever they do now instead of what we decided on. We've been
> having a _lot_ of that happen with Web IDL.  :(
>
> -Boris
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: classes and enumerability

[Yehuda Katz]

On Thu, Jan 29, 2015 at 1:27 PM, Boris Zbarsky  wrote:

> On 1/29/15 4:21 PM, Brendan Eich wrote:
>
>> I was hoping someone deeper into WebIDL (and with more time for it than
>> I have right now :-P) would do that.
>>
>> I missed the part of the first-day TC39 meeting where this was resolved,
>> so I hope someone who was there can speak to the WebIDL plan, if any.
>>
>
> Yes, to make this clear, I was talking about people who were at the
> meeting.  I presume that the Web IDL interactions were considered, since
> they came up in the earlier discussion.


Are you asking what to do about the fact that existing WebIDL "classes"
produce enumerable properties that probably can't be made non-enumerable
without breaking the web?


>
>
> -Boris
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: classes and enumerability

[Yehuda Katz]

Very glad to see this happen!

Yehuda Katz
(ph) 718.877.1325

On Thu, Jan 29, 2015 at 11:55 AM, Brendan Eich  wrote:

> Announcement: ES6 class method syntax makes a non-enumerable property of
> the method's name on the class prototype. That is all. :-)
>
> /be
>
>
> Brendan Eich wrote:
>
>> Herby Vojčík wrote:
>>
>>> Personally, I have always believed we are going down the wrong path by
>>>> switching (from the original max-in class design) to making methods
>>>> defined within a class definition enumerable.
>>>>
>>>
>>> Yes, please, if possible, go back to non-enum methods. I was writing at
>>> that time as well, but things ended up enumerable. I even cited a
>>> real-world example (Amber objects used in jQuery API as options objects),
>>> where enum methods broke the functionality, but non-enum methods allowed
>>> things to work.
>>>
>>
>> On the agenda for next week, at 4(iii):
>>
>> https://github.com/tc39/agendas/blob/master/2015/01.md
>>
>> /be
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

[Yehuda Katz]

bz said:

> ES also allows other "exotic objects" that define some other behavior
> for those internal methods, but requires that the invariants be
> preserved.

Hixie said:

So one option would be to just say that WindowProxy is not an ES object.

---

If it's available to JavaScript consumers it must look like an object that
obeys ES invariants to JavaScript consumers. No (new, ugh) exceptions.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import script --> .esm

[Yehuda Katz]

On Thu, Sep 11, 2014 at 12:02 AM, Kevin Smith  wrote:

>
> There's a difference between "ZOMG WORKING IN SECRET" and talking to
>> people and working on something privately that is still being fleshed out.
>>
>
> Hmmm...  In many other circles "talking to people and working on
> something" doesn't entail working in private.  I've witnessed a repeated
> unwillingness to engage es-discuss or the broader community on some topics
> over the last year or two.  Sorry to have to put it that way, and no
> disrespect, but that's how it is. : /
>

If you're talking about modules, I hardly think that creating a reasonable
fidelity transpiler in public, personally using it in my own (somewhat
popular) open source projects, and working with the wider open source
community qualifies as an unwillingness to engage.

Indeed, the vast majority of the changes to the module syntax over the past
year have come from direct feedback from community members who were
attempting to use the transpiler, and other community members who have
built polyfills of other parts of the system.

If you're talking about long, endless threads on es-discuss mostly
rehashing the same topics over and over again, largely by people without
usage experience, I would suggest that "es-discuss" is not the equivalent
of "the broader community". (which is not to say that feedback from
es-discuss is ignored, just that there reaches a point where the salient
points have already been made and are simply being rehashed).

Different people work in different ways. Personally, I try to give people
working on standards the benefit of the doubt, especially at early stages
when spec champions are still largely gathering feedback from people. You
may find it useful to present drafts of ongoing work while still deep in
the information gathering phase, but not everyone works that way. A bit of
empathy would go a long way here.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import script --> .esm

[Yehuda Katz]

There's a difference between "ZOMG WORKING IN SECRET" and talking to people
and working on something privately that is still being fleshed out.

Not every document on my laptop (or yours) is sufficiently ready for public
consumption for me to put it on Github, even though I put many documents,
in various levels of completion, on Github. Using a term like "secret" to
refer to in-progress work is unnecessary inflammatory.

Yehuda Katz
(ph) 718.877.1325

On Wed, Sep 10, 2014 at 11:20 AM, Anne van Kesteren 
wrote:

> On Wed, Sep 10, 2014 at 6:14 PM, Brendan Eich  wrote:
> > RFC4329 rightly favors application/ -- but this is all beyond the scope
> of
> > ECMA-262. Do Not Want TC39 deciding suffixes. Let developers develop
> > conventions. (Just so long as they do not sound like skin diseases.)
>
> Well the default browser loader which is still secret(?) purportedly
> standardizes on a "js" suffix. That is probably why this came up.
>
> (I think text/javascript is just fine btw. text/* works great for HTML
> and CSS too. In any event, for the purposes of the browser JavaScript
> does not really have a MIME type. We parse anything we get...)
>
>
> --
> http://annevankesteren.nl/
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: include

[Yehuda Katz]

You could imagine a loader plugin that enabled:

import "legacy:foo";

Which would evaluate the module in a script context.

Yehuda Katz
(ph) 718.877.1325


On Mon, Jul 14, 2014 at 9:20 PM, John Barton  wrote:

> Sorry, I was imagining a specific scenario without giving the specifics:
>   include 'foo';  // foo is conventional JS, not a module
>
> I have written on global in a module, it works ok, but the goal was
> specifically to mutate global with code written in a module.
>
> Here I have given code, designed to be loaded with a 

Re: include

[Yehuda Katz]

There is also:

import "foo";

Yehuda Katz
(ph) 718.877.1325


On Mon, Jul 14, 2014 at 6:24 PM, Sam Tobin-Hochstadt 
wrote:

> Why not:
>
> import {} from 'foo';
>
> or
>
> import * as f from 'foo';
>
> This is assuming that there are no other desired exports -- if there
> are, then the case is even easier.
>
> Sam
>
> On Mon, Jul 14, 2014 at 8:37 PM, John Barton 
> wrote:
> > In the module system we issue
> >import {foo} from 'foo';
> > and the Loader computes an address, say foo.js, fetches the resource and
> > compiles it. If the content of foo.js has no dependencies, it is
> evaluated,
> > then the importer is evaluated. Yay!
> >
> > Now suppose that foo.js defines a global value. Oh bad sure, but
> sometimes
> > you have to play cards you are dealt. We still depend upon foo.js, bad or
> > not bad.
> >
> > In the current module system we have to abandon ship. In our importer we
> > need to:
> >   // WARNING pre-load foo.js somehow!
> >
> > Now imagine if we could issue
> >include 'foo';
> > and the Loader computes an address, say foo.js,fetches the resource and
> > compiles it. Since the content has no dependencies, it is evaluated, then
> > the importer is evaluated. Yay!
> >
> > On now back to preloading somehow,
> > jjb
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Object.observe

[Yehuda Katz]

At the last meeting, I expressed some concern I had about Object.observe
based on feedback I got from Kris Selden of the Ember Core team (the
primary maintainer of our binding system and all-around performance guru).

At the meeting, I was under the wrong impression that Kris had attempted to
implement the Ember binding system on top of Google's Object.observe
polyfill. It turns out that his feedback was based on an analysis of the
API, not an actual implementation attempt.

He has since had a conversation with Rafael and has come to the conclusion
that there are no performance blockers in the current API. He is persuaded
that the current API offers enough capabilities so that his initial
performance concerns could be worked around with additional userland
bookkeeping.

Kris and I both still have concerns with the ergonomics of the API, and
believe that the workarounds we arrived at with Raf will end up being
commonly necessary even in basic usage and will necessitate wrapper
libraries to avoid infinite observer loop footguns.

Since API ergonomics can be improved over time, and Google seems eager to
move ahead with the API (and is unpersuaded by our ergonomics objections),
let's continue to move this API forward.

Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promise.cast and Promise.resolve

[Yehuda Katz]

On Sat, Feb 15, 2014 at 5:17 AM, Anne van Kesteren  wrote:

> On Fri, Feb 14, 2014 at 10:50 PM, C. Scott Ananian
>  wrote:
> > Since both Chrome and FIrefox have plans to support Promises, feel
> > free to suggest any changes to `es6-shim` which would improve
> > compatibility.  It looks like that at the moment the `es6-shim`
> > implementation is more spec-compliant than either of the shipping
> > implementations?  In particular, we support subclasses.
>
> It will take a long time before browsers support subclassing in
> general as far as I can tell.
>

I don't know where you're getting this from. @@create is the way classes
and subclassing work in ES6, and any browser that wants to implement class
syntax will need to deal with it.

It may not be at the top of anyone's February 2014 hit-list, but I don't
get any sense that classes are low priority for browser vendors either.


>
>
> --
> http://annevankesteren.nl/
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Sept Meeting Notes

[Yehuda Katz]

On Fri, Sep 27, 2013 at 12:37 PM, Kevin Smith  wrote:

>
> Whether you personally use it, for-in is a reality. Introspection of
>> objects happens, so if you ship a library that's putting meta-level
>> properties into objects it needs to make them non-enumerable to be robust
>> in the face of client code that uses for-in but isn't prepared to
>> understand the meta properties.
>>
>>
> Is there a concrete example which shows how enumerability of meta-level
> properties would present a problem for such code?  That might be convincing.
>

Here are some examples:

   - Checking to see whether an object is empty. In Ember we do this, for
   example, to keep track of whether the list of changes to a model has become
   empty (and therefore to mark the object as clean). That's just one example.
   - Iterating over an object to print out a version for inspection.
   Meta-level properties (1) shouldn't be printed in such casual inspections,
   and (2) often contain recursive references that can cause infinite loops.
   Ember hit this issue with JSDump.
   - Iterating over an object in unit testing frameworks to compare for
   "deep equality". For example, you may want to compare whether some object
   is "deep equal" to { foo: bar }, but don't want to include Ember's
   meta-level properties that track observability.

In Ember, we mark our two meta-level properties as non-enumerable after
hitting some of these issues.

It's probably possible to work around these issues carefully, but
non-enumerability eliminated the entire class of problems triggered by
interactions with third-party libraries.


>
>
>> Once again, read the above links. You aren't distinguishing between the
>> ergonomics of the *provider* of a symbol and the *consumer* of a symbol,
>> and it's the latter case that matters. The ergonomics are better for the
>> consumer of a symbol than that of an obfuscated string, especially when
>> working with developer tools or code that manipulates the key and ends up
>> surfacing the obfuscated string.
>>
>
> In re-reading the above links, you seem to be fighting a strawman.  I
> don't propose using GUIDs at all.  That would be awful.  I propose using
> "@"-prefixed strings, whose ergonomics is clearly superior to the
> symbol-based solution.
>
> Yes, prefixed strings don't give you a collision-free guarantee.  Do we
> need that for meta hooks?  Why?
>

Once we start using @foo in ES, libraries will adopt the pattern (just as
they did for dunder properties). Then we'll hit the same issue in ES7 when
we want to add a new property. I've said this a few times in this thread.


>
> Why would you even need to worry about a user-created object
> *accidentally* using a well-known "@"-prefixed string?  Remember, I
> proposed that hooks are always functions, so the "JSON.parse"
> counter-argument doesn't apply.
>

The problem is code written in the ES6 era interacting with well-known
"@"-prefixed Strings created in the ES7+ era (and the same for ES7, ES8+,
etc.)

The "find a sequence of characters that is both ergonomic and not heavily
in use" solution only works one time. If it's indeed ergonomic, it will be
used in userland and then it will fail the "not heavily in use" requirement
in the future.


>
> { Kevin }
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Sept Meeting Notes

[Yehuda Katz]

The problem with the String proposals is that these things are not exactly
Strings. Specifically, we all mostly agree that we want:

* non-enumerability
* throw on coercion to String
* debugger-friendly names
* some degree of non-collision
* decent ergonomics, i.e. ability to easily understand that you're looking
at a collision-resistant key and what it means
* possibly other semantic distinctions that arise over time

It's possible to add these features to Strings (which is what we keep
trying to do), especially with the aid of debugger tools, but it would mean
shoehorning the semantics into a poorly-defined subset of Strings, and thus
polluting the semantics of *all* Strings.

If we want something that's sort of like a String but with a bunch of
semantic distinctions, let's make a new kind of thing.

Yehuda Katz
(ph) 718.877.1325


On Thu, Sep 26, 2013 at 5:22 PM, David Herman  wrote:

> On Sep 26, 2013, at 5:03 PM, Allen Wirfs-Brock 
> wrote:
>
> > I meant, if you didn't have symbols you could pretty much do the same
> thing by exporting a name that is bound to the GUID string as its value.
>  That exported name could be imported by clients and used as the friendly
> way to refer to that property name, just like you are suggesting they do
> with Symbol values.
>
> The difference is the ergonomics. The GUID shows up in your developer
> tools, when you introspect on the property names, etc. The symbol shows up
> as a symbol, which is conceptually cleaner and vastly more readable. If you
> have 5 different GUIDs in your object, and you inspect the object in
> developer tools, you have to go and manually look up which one corresponds
> to which abstraction. Or if you use a human-readable but mildly obfuscated
> name, then you need a naming convention, and then you have the collision
> problem all over again. Finally, you can use an obfuscated GUID-y suffix
> but with a human-readable prefix, so at least humans have some hope of
> reading it, but you've still made your users' lives unpleasant.
>
> With symbols you give all your users the pleasant experience of a clean
> distinction between symbol and string. And with some sort of registry, you
> can provide an abstraction that registers the symbol so that multiple
> realms can even coordinate on the symbol even in the face of multiple
> distinct copies of the library.
>
> Am I not explaining this well? I feel like I've been trying to make this
> point several times over in this thread. One of the biggest issues with
> GUID's -- the thing that makes everyone turn three shades of green every
> time it gets proposed -- is the ergonomics. One of the main complaints
> people made about symbols was that it's not possible to do userland
> coordination across realms. While I don't think we have to solve that for
> ES6, my examples demonstrate that with a registry symbols absolutely can
> provide cross-realm coordination while tangibly beating out string
> conventions for ergonomics/usability/readability.
>
> Dave
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Sept Meeting Notes

[Yehuda Katz]

On Thu, Sep 26, 2013 at 4:20 PM, Allen Wirfs-Brock wrote:

>
> On Sep 26, 2013, at 4:12 PM, Brandon Benvie wrote:
>
> > On 9/26/2013 4:09 PM, Allen Wirfs-Brock wrote:
> >> The newness was using using string literals+ concise methods to write
> such meta=level methods.
> >>
> >> What it brings to the table is that it address the meta stratification
> issue in a reasonable manner without having to add anything (other than the
> use of the hooks) to the ES5 level language.  (and I'm ignoring the
> enumerability issues).
> >
> > I don't see how any of the string key proposals so far are different
> from __proto__, which we agree is not an adequate level of stratification
> (none basically).
>
> It moves the stratified names out of the syntactic space that JS
> programmers typically use for their own names.  The Dunder names don't have
> that characteristics plus various sort of "_" prefixing is already used by
> many programmer at the application level.
>

Agreed, but this problem will come right back in ES7. Private names don't
solve this issue because of where they trap, so we don't need a temporary
patch, but a permanent solution.


>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Sept Meeting Notes

[Yehuda Katz]

On Thu, Sep 26, 2013 at 4:12 PM, Brandon Benvie  wrote:

> On 9/26/2013 4:09 PM, Allen Wirfs-Brock wrote:
>
>> The newness was using using string literals+ concise methods to write
>> such meta=level methods.
>>
>> What it brings to the table is that it address the meta stratification
>> issue in a reasonable manner without having to add anything (other than the
>> use of the hooks) to the ES5 level language.  (and I'm ignoring the
>> enumerability issues).
>>
>
> I don't see how any of the string key proposals so far are different from
> __proto__, which we agree is not an adequate level of stratification (none
> basically).


Indeed. The reason dunder doesn't work is that it's used in user-land due
to the spec's usage, which means that it's not implausible that some
library uses __iterator__ already for a different (or even similar) purpose.

The @ prefix dodged that bullet today (although it may introduce
generated-code hazards), but it opens up exactly the same problem for the *
next* time we need a new unique name.


>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Sept Meeting Notes

[Yehuda Katz]

I don't understand why any registry is needed. Imagine a module
"ember/symbols" implemented like this, assuming some sharedSpace that
modules have access to cross-realms.

```
var guid = "", symbol;
if (sharedSpace[guid]) {
  symbol = sharedSpace[guid];
} else {
  symbol = sharedSpace[guid] = new Symbol("friendly name");
}

export meta = symbol;
```

And then in any realm:

```
import { id } from "ember/symbols";

// use `id` symbol
```

So you still coordinate over Strings, but you don't need a VM-level
registry, just a user-land one.

Yehuda Katz
(ph) 718.877.1325


On Thu, Sep 26, 2013 at 4:07 PM, Mark S. Miller  wrote:

> I think we swept the collision problem under the registry rug. Let's start
> by discussing registry designs assuming we do have Symbols. Let's see if we
> can design a registry that allows cross-realm duck typing without
> re-introducing the same possibility of accidental collision that we'd have
> without Symbols. Note: For this question, malicious collision is not an
> issue.
>
>
> On Thu, Sep 26, 2013 at 4:02 PM, Rick Waldron wrote:
>
>>
>>
>>
>> On Thu, Sep 26, 2013 at 6:51 PM, Domenic Denicola <
>> dome...@domenicdenicola.com> wrote:
>>
>>>
>>>
>>> > On Sep 26, 2013, at 18:49, "Yehuda Katz"  wrote:
>>> >
>>> > Private state doesn't satisfy these requirements because they trap on
>>> the wrong side of the proxy.
>>>
>>> Agreed, in many cases I don't want private state; I *want* something
>>> that can be copied by Object.mixin, for example. For private state, weak
>>> maps are fine, and used today already.
>>>
>>
>>
>> Agreed with Yehuda and both of Domenic's points. I don't need/want Symbol
>> for private anything—I want it for cases that don't deserve a WeakMap,
>> should be reflected and can be "seen" by Object.getOwnPropertySymbols(),
>> but want to avoid the possibility of collision.
>>
>> Rick
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Sept Meeting Notes

[Yehuda Katz]

Sorry, that was too short.

I don't understand what "using string literal specified, non-identifier
property names" brings to the table to fundamentally alter the constraints
that we've been working with that led to the consensus at the last f2f.

Yehuda Katz
(ph) 718.877.1325


On Thu, Sep 26, 2013 at 3:58 PM, Yehuda Katz  wrote:

>
>
> Yehuda Katz
> (ph) 718.877.1325
>
>
> On Thu, Sep 26, 2013 at 3:57 PM, Allen Wirfs-Brock 
> wrote:
>
>>
>> On Sep 26, 2013, at 3:50 PM, David Herman wrote:
>>
>> > On Sep 26, 2013, at 3:48 PM, Domenic Denicola <
>> dome...@domenicdenicola.com> wrote:
>> >
>> >> I don't understand why this is happening. There was fairly strong
>> consensus on symbols at the last meeting, and nothing new has been brought
>> to the table. Why are people's opinions suddenly changing? Vague
>> fearmongering about "complexity"? Symbols are a good solution to a real
>> problem, much better than strings.
>> >
>> > +so much
>> >
>> > I am very disappointed by this thread.
>>
>> Actually, something new was brought to the table.  The convention of
>> using string literal specified, non-identifier property names for
>> stratified meta operations.
>>
>
> How is that new?
>
>
>>
>> It's enough to at least spend a few minutes to consider whether that is
>> good enough to do for the primary use case (in the ES spec,) for Symbols.
>>
>> Allen
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Sept Meeting Notes

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Thu, Sep 26, 2013 at 3:57 PM, Allen Wirfs-Brock wrote:

>
> On Sep 26, 2013, at 3:50 PM, David Herman wrote:
>
> > On Sep 26, 2013, at 3:48 PM, Domenic Denicola <
> dome...@domenicdenicola.com> wrote:
> >
> >> I don't understand why this is happening. There was fairly strong
> consensus on symbols at the last meeting, and nothing new has been brought
> to the table. Why are people's opinions suddenly changing? Vague
> fearmongering about "complexity"? Symbols are a good solution to a real
> problem, much better than strings.
> >
> > +so much
> >
> > I am very disappointed by this thread.
>
> Actually, something new was brought to the table.  The convention of using
> string literal specified, non-identifier property names for stratified meta
> operations.
>

How is that new?


>
> It's enough to at least spend a few minutes to consider whether that is
> good enough to do for the primary use case (in the ES spec,) for Symbols.
>
> Allen
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Sept Meeting Notes

[Yehuda Katz]

If that's the case, we haven't thought the registry through well enough.
You should get the cross-realm symbol through imports.

Yehuda Katz
(ph) 718.877.1325


On Thu, Sep 26, 2013 at 3:48 PM, Mark S. Miller  wrote:

> Once you add the registry, all these accidental collisions problems come
> back. If you don't add a registry, you lose the ability to duck type across
> realms.
>
>
> On Thu, Sep 26, 2013 at 3:45 PM, Yehuda Katz  wrote:
>
>> I prefer Symbol names for the reasons I said at the last meeting:
>>
>> * Non-enumerability by default (the other solutions presented in this
>> thread are finicky, harder to explain, and potentially error-prone).
>> * Guaranteed duck-testability: if an object tests positive for
>> iterability, it much be intentional. Once we start using @ as a symbolic
>> prefix, userland libraries will likely start to use it too, making
>> duck-tests of future names inconclusive. I'm also not convinced that @foo
>> isn't already used for this purpose in the wild, but even if that's true,
>> it only solves the issue for one generation.
>> * Intention-preserving: You get to use a short, English name as the
>> method name with just a bit of syntactic chrome, and you don't have to
>> worry about the tradeoff between collisions and leaking indecipherable
>> names to debugging.
>>
>> Yehuda Katz
>> (ph) 718.877.1325
>>
>>
>> On Thu, Sep 26, 2013 at 3:33 PM, Allen Wirfs-Brock > > wrote:
>>
>>>
>>> On Sep 26, 2013, at 3:13 PM, Rick Waldron wrote:
>>>
>>>
>>>
>>>
>>> On Thu, Sep 26, 2013 at 6:02 PM, Erik Arvidsson <
>>> erik.arvids...@gmail.com> wrote:
>>>
>>>> No surprise here, but I also support using "@" methods.
>>>
>>>
>>> I don't. Please see my response to Kevin Smith:
>>> https://mail.mozilla.org/pipermail/es-discuss/2013-September/033720.html
>>>
>>>
>>> I'm also in
>>>> favor of making methods non enumerable by default. This makes them
>>>> more consistent with what we have in ES today.
>>>
>>>
>>> That might be the case for methods defined on prototypes of built-in
>>> objects, but it's absolutely not the case for user land code. Please see
>>> the examples in my previous response to Allen:
>>> https://mail.mozilla.org/pipermail/es-discuss/2013-September/033725.html
>>>
>>>
>>> so name your events property "@RickWaldron@events".
>>>
>>> If somebody subclasses Emitter and know that property name, then they
>>> must be doing something intentional.
>>>
>>> Unique Symbols don't guarantee that sort of integrity. All you've
>>> accomplish by using them as in your example is to minimize that chance that
>>> somebody else doesn't accidentally use the same property name for some
>>> other purpose.  Naming your property "@RickWaldron@events" also makes
>>> such accidentally unlikely.
>>>
>>> Allen
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Sept Meeting Notes

[Yehuda Katz]

Private state doesn't satisfy these requirements because they trap on the
wrong side of the proxy.

Yehuda Katz
(ph) 718.877.1325


On Thu, Sep 26, 2013 at 3:47 PM, Allen Wirfs-Brock wrote:

>
> On Sep 26, 2013, at 3:39 PM, Rick Waldron wrote:
>
> >
> > The Symbol isn't exposed so therefore can't accidentally be used to
> accidentally pave over the subclass instance object's events cache. As far
> as the "@RickWaldron@events" Hungarian notation monstrosity is concerned:
> the first thing I thought when I saw this was that it would never pass any
> practitioner's peer code review. This is worse then implied
> collision-safety (or privacy, HA!) of "_"-prefixed properties—worse because
> the language is saying "go ahead and do this".
>
> Oh, that's not Hungarian notation, it's just a name space qualifier.
>
> But, if you assume that we will added a real private state mechanism into
> "ES 6.1" or "ES6.2" will Symbol really carry its weight looking back 10
> years from now?
>
> Allen
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Comments on Sept Meeting Notes

[Yehuda Katz]

I prefer Symbol names for the reasons I said at the last meeting:

* Non-enumerability by default (the other solutions presented in this
thread are finicky, harder to explain, and potentially error-prone).
* Guaranteed duck-testability: if an object tests positive for iterability,
it much be intentional. Once we start using @ as a symbolic prefix,
userland libraries will likely start to use it too, making duck-tests of
future names inconclusive. I'm also not convinced that @foo isn't already
used for this purpose in the wild, but even if that's true, it only solves
the issue for one generation.
* Intention-preserving: You get to use a short, English name as the method
name with just a bit of syntactic chrome, and you don't have to worry about
the tradeoff between collisions and leaking indecipherable names to
debugging.

Yehuda Katz
(ph) 718.877.1325


On Thu, Sep 26, 2013 at 3:33 PM, Allen Wirfs-Brock wrote:

>
> On Sep 26, 2013, at 3:13 PM, Rick Waldron wrote:
>
>
>
>
> On Thu, Sep 26, 2013 at 6:02 PM, Erik Arvidsson 
> wrote:
>
>> No surprise here, but I also support using "@" methods.
>
>
> I don't. Please see my response to Kevin Smith:
> https://mail.mozilla.org/pipermail/es-discuss/2013-September/033720.html
>
>
> I'm also in
>> favor of making methods non enumerable by default. This makes them
>> more consistent with what we have in ES today.
>
>
> That might be the case for methods defined on prototypes of built-in
> objects, but it's absolutely not the case for user land code. Please see
> the examples in my previous response to Allen:
> https://mail.mozilla.org/pipermail/es-discuss/2013-September/033725.html
>
>
> so name your events property "@RickWaldron@events".
>
> If somebody subclasses Emitter and know that property name, then they must
> be doing something intentional.
>
> Unique Symbols don't guarantee that sort of integrity. All you've
> accomplish by using them as in your example is to minimize that chance that
> somebody else doesn't accidentally use the same property name for some
> other purpose.  Naming your property "@RickWaldron@events" also makes
> such accidentally unlikely.
>
> Allen
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.values and/or Object.forEach ?

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Sat, Jun 8, 2013 at 9:23 PM, Dmitry Soshnikov  wrote:

> I might be missing something, but how for-of help solving parametrized
> enumeration (that is, specifying an action applied on a value/key in a
> functional style)?
>
> I see clear use-case of Object.values(...) in addition to
> Object.keys(...), and it has nothing to do with for/of enumeration.
>
> Why refuse a convenient library method and force users to 1) let values =
> []; 2) for (v of values(o)) { values.push(v); }, if it can be just let
> values = Object.values(o);?
>

I'm confused. Your example shows (correctly) that a `values` method exists
that does what you want. What more are you asking for?


> Why refuse a _parametrized_ functional iteration such as Object.forEach(o,
> parametrizedAction) and force users to write different static for-of loops
> with own loop body per each condition, if this condition can be passed as a
> function?
>

I am personally in favor of a collections module that works across any
iterable. I don't think we have anything on tap for ES6, but it would be
trivial to write in pure JS in the ES6 timeframe and I don't see any reason
it couldn't be folded in to ES7 once it gets some real-world usage.


> P.S.: for consistency with [].forEach, it probably would make sense having
> {}.forEach, but it's O.prototype pollution.
>
> Dmitry
>
> On Jun 7, 2013, at 10:18 AM, Dean Landolt wrote:
>
> The for/of iterators solve this nicely. This is definitely something that
> comes up a lot though, and this seems like a very handy cowpath to pave. If
> it were spec'd I'd suggest the naming and argument values should align with
> the for/of variants.
>
>
> On Fri, Jun 7, 2013 at 12:57 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> it comes out from time to time devs would like to have `Object.values()`
>> as equivalent of `Object.keys()` except the returned array would contain
>> values.
>>
>> Better than repeated
>> `Object.keys(obj).map(function(p){return this[k];}, obj);`
>> all over
>>
>> but probably less useful than a more generic `Object.forEach(obj,
>> callback, thisValue)` where `callback` would receive `(value, key,
>> originalObject)` and `thisValue` as context.
>>
>> This is consistent with `Array#forEach` and could simplify `for/in` loops
>> passing over own enumerable properties only, as keys would do.
>>
>> Thoughts ?
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modularity: ES6 modules vs. HTML imports vs. asm.js

[Yehuda Katz]

I started a conversation with Rafael Weinstein last week about the
possibility of integrating these systems. I believe that it is possible and
desirable, but there are many open questions to answer still.

It will be easier to begin the discussion seriously once the Loader API is
entirely specified, imho.

Yehuda Katz
(ph) 718.877.1325


On Sat, Jun 8, 2013 at 7:33 AM, Sam Tobin-Hochstadt wrote:

> HTML imports are importing HTML, not JS.  Coordination is always good,
> but I don't know what that would entail here.
>
> asm.js modules have some specific needs, and it may or may not be able
> to use ES6 modules. I'll let Dave speak to that.
>
> Sam
>
> On Sat, Jun 8, 2013 at 9:56 AM, Axel Rauschmayer  wrote:
> > With Web Components, we also get HTML Imports [1]. This seems like yet
> > another modularity construct on the web. Would it make sense to
> coordinate
> > this with ES6 modules? I’m also hoping/assuming that asm.js will
> eventually
> > use ES6 modules(?)
> >
> > [1] http://www.w3.org/TR/2013/WD-html-imports-20130514/
> >
> > --
> > Dr. Axel Rauschmayer
> > a...@rauschma.de
> >
> > home: rauschma.de
> > twitter: twitter.com/rauschma
> > blog: 2ality.com
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: JSON Duplicate Keys

[Yehuda Katz]

At two TC39 meetings, members of TC39 expressed deep concern about the
prospect of incompatible changes to JSON by the IETF. It seems as though
the IETF would like to consider one or more incompatible changes to JSON as
part of this standardization process. There is extremely little support on
TC39 for such changes.

We could keep an eye on the IETF list for the introduction of incompatible
changes and keep popping up to express this sentiment, but I believe that
it would be better if any proposed incompatible changes were raised here
before there was serious consideration in the IETF.

I do not believe that "you should have been paying attention" will be
sufficient to gain consensus on TC39 for incompatible changes.

Yehuda Katz
(ph) 718.877.1325


On Sat, Jun 8, 2013 at 10:50 AM, Paul Hoffman wrote:

> Just a note to emphasize what was said a few days ago: the revision of the
> JSON RFC is being discussed in the IETF right now. This topic is certainly
> one of the many that the JSON WG is discussing. If you want to participate
> in the conversation in a way that will affect the new RFC, you should
> probably be doing so in the JSON WG. Info at
> https://www.ietf.org/mailman/listinfo/json
>
>
> On Fri, Jun 7, 2013 at 9:51 AM, David Bruant  wrote:
>
>>  Le 07/06/2013 06:41, Kevin Smith a écrit :
>>
>>
>>   +∞
>>>
>>> "Get off my lawn!" comment (I will tag in and tag Doug out of the grumpy
>>> old men smackdown ring): you kids stop fiddling with JSON. It needs
>>> "fixing" like it needs a hole in the head.
>>>
>>>
>>  Comment syntax sure would be nice though : P
>>
>> As others suggested, create a different format that looks like JSON and
>> has comments. And just add yet another build-step to your build process.
>> Very much like what happens with SASS (comments are remove when compilation
>> to CSS occurs)
>>
>> David
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minor questions on new module BNF

[Yehuda Katz]

On Tue, Jun 4, 2013 at 8:11 AM, Jason Orendorff
wrote:

> On Mon, Jun 3, 2013 at 11:33 AM, Yehuda Katz  wrote:
>
>> I've advocated for this in the past. I believe it should be allowed.
>>
>> Separately, I would like this form to be specified as deferring execution
>> until bindings are explicitly imported (from another module), or a
>> synchronous `System.get` call is made.
>>
>
> It makes the static import language a bit more expressive, but why is it
> necessary?
>
> For performance? The alternative, if a module has expensive
> initialization, would be to have it initialize itself more lazily.
>
>  This would make it possible to guarantee that a synchronous `System.get`
>> will succeed, without being forced to execute the module first.
>>
>
>  It would definitely make that possible, but what `System.get()` use case
> are you looking to support? To my mind `System.get()` is like examining
> `$LOADED_FEATURES` in Ruby or `sys.modules` in Python; those use cases
> exist, but the kind of code you're writing when you touch those is
> typically either an egregious hack or it's generic across all modules,
> right? They don't need or merit syntactic support.
>
> I want to understand the motivation, because Domenic asked for syntax that
> just loads and runs a module, without bindings. It seems like we could
> support that feature with a tweak of the grammar, but you're proposing
> taking that exact syntax and using it for something else. I expect people
> trying to load and run a module will greatly outnumber people trying to
> load and *not* run a module.  Wouldn't we be astonishing more people by
> doing it your way?
>

I'm happy to give in here, but I'm nervous about how strongly Domenic wants
to connect the timing of imports with execution in people's minds.

If people actually write code like that, it's going to be a bad time.


>
>
> -j
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minor questions on new module BNF

[Yehuda Katz]

On Tue, Jun 4, 2013 at 6:29 AM, Kevin Smith  wrote:

>
>
>> Yep, agreed. (To be pedantic, it's not that it defers execution so much
>> as that it doesn't force execution.)
>>
>
> Can you explain?  I would naively expect for this:
>
> // someModule
> console.log("someModule");
>
> // main
> import "someModule";
> console.log("main");
>
> when executing main, to output:
>
> > someModule
> > main
>

In general, expectations about side-effects that happen during module
loading are really edge-cases. I would go as far as to say that modules
that produce side effects during initial execution are "doing it wrong",
and are likely to produce sadness.

In this case, the `import` statement is just asking the module loader to
download "someModule", but allowing the app to move on with life and not
bother executing it. This would allow an app to depend on a bunch of
top-level modules that got executed only once the user entered a particular
area, saving on initial boot time.


>
> Thanks!
>
> { Kevin }
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: May 21, 22, 23 TC39 Meeting Notes

[Yehuda Katz]

On Mon, Jun 3, 2013 at 2:02 AM, Andreas Rossberg wrote:

> On 2 June 2013 22:19, Dmitry Soshnikov  wrote:
> >> 4.10 Modules
> >>
> >> STH: Progress since last meeting. Discuss “module naming”, “naming
> standard
> >> modules”.
> >> STH: http://wiki.ecmascript.org/doku.php?id=harmony:modules
> >> STH: Wiki is up to date with the current proposal. Spec is “wiki
> complete”.
> >> Jason Orendorff of Mozilla has worked on flushing out semantic issues.
> Moz
> >> is implementinb parsing of modules.
> >> STH: Syntax: Made a couple of changes.
> >> A. To support anonymous exports
> >>
> >>   export default expr;
> >>
> >>   import $ from ‘jquery’;  // imports default anonymous export
> >
> > I missed that, and current wiki draft doesn't explain it either, but --
> what
> > was a rationale of using string literals on imports, and, worth, also for
> > module names at define?
>
> Modules won't have lexical scope, they will just be named by (more or
> less) arbitrary strings in a single (per-loader) global name space.
> That was a change made last November, and some of us (well, me, in
> particular) have disagreed with it ever since. You can read up on most
> of the pro & con arguments in the recent monster thread starting here:
>
> https://mail.mozilla.org/pipermail/es-discuss/2013-April/030165.html
>
> FWIW, I still think this is a fundamental mistake, but it is now
> pretty much set in stone. Hopefully, we'll get proper lexical scoping
> in ES7.
>

I'm personally in favor of getting lexical scope in ES7, and retrofitting
the current module declarations so that they desugar into the creation of a
lexical module and a declarative registration of that module in the
registry.

```
module "foo" {

}

// would be equivalent to something like

module  {

}

export module  as "foo";
```

We discussed this briefly at the last meeting on a whiteboard. It requires
some more thought, and I'd love to have you help work on something like
this for ES7.

I'm glad that we came to a (grudging) consensus on moving forward with the
current ES6 proposal for ES6, with a clear idea on where to start for ES7.


> /Andreas
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Minor questions on new module BNF

[Yehuda Katz]

On Mon, Jun 3, 2013 at 12:24 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> From: sam...@gmail.com [mailto:sam...@gmail.com] On Behalf Of Sam
> Tobin-Hochstadt
>
> > The idea here is that modules will typically be written in files like
> "compiler/Lexer.js", where the starting grammar production *is*
> `ModuleBody`.
>
> Ah, that makes sense! It's a nice way of prohibiting `export
> function foo() { }` as well, assuming inline `

Re: Module Comments

[Yehuda Katz]

One plausible variant to our proposal that might be easier to swallow (as
it doesn't have the special-cased ObjectLiteral problem) is:

   - Replace `export ExportSpecifierSet` with `export ObjectLiteral` for
   static exports
   - Allow `export = foo` (or something like it) for single exports
   - Unify the import syntax to support the full destructuring syntax and
   to work on both static and single exports

This retains the advantages of reducing micro-syntax and reforming import
without forcing an awkward special-casing of `export ObjectLiteral`


On Thu, Dec 6, 2012 at 7:44 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

>  For the record, here's the idea Yehuda and I worked out:
>
> https://gist.github.com/1ab3f0daa7b37859ce43
>
> I would *really* appreciate if people read it (it's easy reading, I
> promise!) and incorporated some of our concerns and ideas into their
> thinking on module syntax.
>
> In general, it tries to eliminate the ExportSpecifierSet and
> ImportSpecifierSet microsyntaxes in favor of standard object
> literal/destructuring forms, respectively. It also made export and import
> syntax symmetric.
>
> It apparently failed to get much traction among committee members, mainly
> because of objections to our reformation of the export-side syntax.
> (Second-hand info.) E.g. the current export function foo() { } was
> preferred to the proposed export { foo() { } }, and---less
> aesthetically---our special behavior for ObjectLiteral expressions over
> other expressions was a bit weird.
>
> I still think the import-side reformation is important and stand by
> everything in the proposal in that regard. As mentioned in other messages
> in this thread, the current form is confusingly dual-natured. And I
> maintain that the incomplete semi-destructuring microsyntax of
> ImportSpecifierSet adds a lot of cognitive burden.
>
> If we can start by fixing the import side, I have some other ideas on how
> to make the export side better that hopefully will be more appealing to the
> committee. But I don't want to try proposing those yet until we can get the
> buy-in on fixing import.
>
>  --
> *From:* es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org]
> on behalf of Erik Arvidsson [erik.arvids...@gmail.com]
> *Sent:* Thursday, December 06, 2012 09:54
> *To:* Kevin Smith
> *Cc:* es-discuss
> *Subject:* Re: Module Comments
>
>
>  On Thu, Dec 6, 2012 at 9:42 AM, Kevin Smith  wrote:
>
>> Dave responded by pointing out that we don't want "from" to have
>> overloaded semantics.  I actually think this form has potential, because it
>> further aligns import with the other binding forms:
>>
>>  var a = x;
>> var { b } = y;
>>
>>  // Symmetry!
>>
>>  import a from "x";
>> import { b } from "y";
>>
>
>  +1
>
>  This also matches what Yehuda and Domenic proposed a few weeks ago.
>
>  --
> erik
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Default value for Map

[Yehuda Katz]

Just to clarify, the existing Map has a first parameter, so there would
need to be some additional API work here (second parameter with undefined
first parameter, second class, `defaultValue` setter, etc.).


On Wed, Nov 28, 2012 at 1:45 PM, Brendan Eich  wrote:

> See also https://mail.mozilla.org/**pipermail/es-discuss/2012-**
> January/019723.html<https://mail.mozilla.org/pipermail/es-discuss/2012-January/019723.html>where
>  defaultdict was raised on es-discuss for the first time (if I'm not
> mistaken).
>
> /be
>
> Yehuda Katz wrote:
>
>> There are many cases involving nested data structures where the ability
>> to define a default value in Maps would be helpful.
>>
>> Straw Man:
>>
>> var map = new Map(=> [])
>> var arr = map.get('foo')
>> arr === map.get('foo') // true
>>
>> This enables:
>>
>> map.get('foo').push(obj)
>>
>> Which would be (*very*) approximately equivalent to:
>>
>>
>> class MapWithDefault extends Map {
>>   constructor(default) {
>> this.defaultValue = default;
>> super();
>>   }
>>
>>   get(key) {
>> if (!this.contains('foo')) {
>>   let value = this.defaultValue(key);
>>   map.set(key, value);
>> }
>>
>> return super(key);
>>   }
>> }
>>
>> --
>> Yehuda Katz
>> (ph) 718.877.1325
>> __**_
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>


-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Default value for Map

[Yehuda Katz]

There are many cases involving nested data structures where the ability to
define a default value in Maps would be helpful.

Straw Man:

var map = new Map(=> [])
var arr = map.get('foo')
arr === map.get('foo') // true

This enables:

map.get('foo').push(obj)

Which would be (*very*) approximately equivalent to:

class MapWithDefault extends Map {
  constructor(default) {
this.defaultValue = default;
super();
  }

  get(key) {
if (!this.contains('foo')) {
  let value = this.defaultValue(key);
  map.set(key, value);
}

    return super(key);
  }
}

-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let and strict mode

[Yehuda Katz]

-- Yehuda Katz
(ph) 718.877.1325
On Nov 18, 2012 4:29 PM, "Brendan Eich"  wrote:
>
> Yehuda Katz wrote:
>>
>> Question: does requiring strict mode for changes that break
compatibility with ES5 really address the 1JS concerns?
>
>
> Yes. 1JS is based on ES5 and so includes strict mode.

I was really asking the below question. I didn't remember that let was
reserved and therefore poses no new compatibility issues.

>
>
>> We're making usages of the identifier let that were valid in ES5 strict
invalid in ES6 strict. Doesn't that violate 1JS?
>
>
> No, you forget that ES5 strict reserves 'let' (and 'yield').

Indeed. Thanks for reminding me.

>
> /be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let and strict mode

[Yehuda Katz]

Question: does requiring strict mode for changes that break compatibility
with ES5 really address the 1JS concerns? We're making usages of the
identifier let that were valid in ES5 strict invalid in ES6 strict. Doesn't
that violate 1JS?


On Sun, Nov 18, 2012 at 7:02 AM, Kevin Smith  wrote:

>
>
> Dave Herman proposed as part of 1JS that module imply strict mode, so let
>> is reserved in module. So that helps.
>>
>
> Sure, for inline modules.  But are externally loaded modules strict as
> well?  I think they should be...
>
> 1. 'let' only in strict code including modules per 1JS as originally
>> proposed.
>>
>> 2. 'let' followed by identifier or { but not LineTerminator.
>>
>> 3. 'let' followed by identifier or { with LineTerminator and other space
>> allowed in between.
>>
>> 4. 'let' followed by identifier, {,  or [ and LineTerminator in between
>> is ok.
>>
>> 5. We could also allow 'let' per (4) in functions not in modules that do
>> not "use strict" but do use new ES6 syntax in their heads, e.g.
>> destructuring parameters, default parameters, rest parameters. Those head
>> features could arguably opt into 'let' syntax but not strict mode.
>>
>
> Anything other than (1) neuters either the let statement or let
> identifiers - yuck.  As Domenic says, most new code will go in modules
> anyway.
>
> - Kevin
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A new function name property proposal

[Yehuda Katz]

 original case, Objective-J) would probably
continue to benefit from more control over the name.

*TL;DR*
*
*
I would really like to see Dave's Function.create(name, call, construct,
proto) proposal come to pass. Fleshing out static name extraction as
described above would be a big benefit to a lot of common uses, and I am in
favor of it. Direct control of the name, not static inference, is needed
for imperative class-like abstractions.

On Sat, Nov 17, 2012 at 7:44 PM, Brandon Benvie
wrote:

> Excellent! I must admit to having a pretty ridiculous obsession with the
> name property of functions in particular, so I would be much delighted to
> see improvements and standardization come to it.
>
>
> On Sat, Nov 17, 2012 at 9:06 PM, Brendan Eich  wrote:
>
>> Brandon: thanks for reviving and revising my old strawman. I will edit
>> your proposed changes in (and let you and the list know when I'm done so
>> you can review) and present at the TC39 meeting in the last week of
>> November. Thanks again, great work!
>>
>> /be
>>
>> Brandon Benvie wrote:
>>
>>> Declarative scope...not decorative scope. Curses auto correct fail.
>>> __**_
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let and strict mode

[Yehuda Katz]

On Sat, Nov 17, 2012 at 6:06 PM, Brendan Eich  wrote:

> Dave Herman proposed as part of 1JS that module imply strict mode, so let
> is reserved in module. So that helps.
>
> For let outside of modules, we could contextually parse let at start of
> statement if followed by an identifier or a { that starts an object
> pattern. We could even allow LineTerminator after let, and perhaps should
> try to get away with that.
>
> But if we allow LineTerminator and risk some backward incompat, can we up
> the ante by allowing [ after let?
>
> Who knows, but we have some choices:
>
> 1. 'let' only in strict code including modules per 1JS as originally
> proposed.
>

This would essentially be sending the message: "get your ES5 house in order
before trying to use ES6 binding forms". I'm not sure how I feel about
this, but getting people to clean up code invalid in ES5 strict mode is a
nice carrot.


> 2. 'let' followed by identifier or { but not LineTerminator.
>
> 3. 'let' followed by identifier or { with LineTerminator and other space
> allowed in between.
>
> 4. 'let' followed by identifier, {,  or [ and LineTerminator in between is
> ok.
>

Trying to identify `let` usage by known ES6 syntax could be future hostile,
by limiting our ability to extend the BindingList grammar. It would
essentially restrict us from adding any prefixes to BindingIdentifier that
could be ambiguous in ES5. I'm not fully enough aware of all of the
historical proposals to know whether any of these could become issues in
the future: let ?foo, let ^foo, let &foo. Maybe there's something I'm
missing and this category of problem could not arise?


> 5. We could also allow 'let' per (4) in functions not in modules that do
> not "use strict" but do use new ES6 syntax in their heads, e.g.
> destructuring parameters, default parameters, rest parameters. Those head
> features could arguably opt into 'let' syntax but not strict mode.
>

I'd be worried that it would confusingly break refactored code:

function isPermitted(user) {
  var permissions = [].slice.call(arguments, 1),
  let = authorize(permissions);

  if (!let) { return false; }
  else return permissions;
}

// to

function isPermitted(user, ...permissions) {
  var let = authorize(permissions);

  if (!let) { return false; }
  else return permissions;
}


> Comments?
>
> /be
>
> Kevin Smith wrote:
>
>>
>> var let = function() {};
>> let();
>>
>>
>> If let is a contextual keyword (in non-strict mode of course), then we
>> can look ahead to the token after `let` to validate it.  An open paren
>> cannot follow a let *keyword*, so therefore it must be an identifier.
>>
>>var let = { it: "be" };
>> let.it <http://let.it> // be
>>
>>
>>
>> Same logic applies.  A dot cannot follow a let keyword so we parse it as
>> an identifier.
>>
>> On the other hand, an open square bracket *can* follow a let keyword (by
>> array destructuring), so we have a potential ambiguity there.
>>
>> - Kevin
>>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: let and strict mode

[Yehuda Katz]

Doesn't the same problem exist with:

var let = function() {};
let();

Or:

var let = { it: "be" };
let.it // be


On Fri, Nov 16, 2012 at 9:19 AM, Herby Vojčík  wrote:

>
>
> Kevin Smith wrote:
>
>>  var let = [], num = 0;
>>
>>  let[num] = f();
>>
>
> Awww, that's hard. I am really curious how this one is solved.
>
>
>> - Kevin
>>
>
> Herby
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Synchronous Object.observe but Asynchronous Object.unobserve ?

[Yehuda Katz]

In my experience, it is very common to want to process changeRecords that
were created, even if you letter turned off the observer. Turning off
observers (in particular, temporarily), can be useful for avoiding certain
kinds of cycles when creating bidrectional links.


On Sat, Nov 3, 2012 at 11:19 PM, Rafael Weinstein wrote:

> If you wish, you can maintain a WeakMap of observed objects. If you
> wish to never process a changeRecord for an object you've stopped
> observing, you can simply check the WeakMap to see if it's still
> observed.
>
> On Fri, Nov 2, 2012 at 9:50 PM, Andrea Giammarchi
>  wrote:
> > fair enough, but I want to know what I am seeing is recorded and the TV
> is
> > switched off ... how? Flagging records? Flagging objects? Via
> getNotifier ?
> >
> >
> > On Fri, Nov 2, 2012 at 11:56 AM, Erik Arvidsson <
> erik.arvids...@gmail.com>
> > wrote:
> >>
> >> On Fri, Nov 2, 2012 at 12:22 PM, Andrea Giammarchi
> >>  wrote:
> >> > How to make this simple ... if I switch off the TV I don't expect any
> >> > eco
> >> > after ... I don't care about the program, it should not bother me.
> >>
> >> If you stick to the TV analogy... You don't want Tivo to erase what it
> >> just recorded just because you stopped recording.
> >>
> >> --
> >> erik
> >
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: thoughts the (re)organization of the specification?

[Yehuda Katz]

Same here. Carpe diem.

-- Yehuda Katz
(ph) 718.877.1325
On Nov 2, 2012 7:24 PM, "Kevin Smith"  wrote:

> Just speaking as a spec reader, I say go for it.
>
> - Kevin
>
>
> On Fri, Nov 2, 2012 at 6:08 PM, Allen Wirfs-Brock 
> wrote:
>
>> In both ES5 and ES6 (so far) we have generally tried to maintain the
>> section structure of the previous editions.  Occasionally we have had to do
>> some minor subsection renumbering (or not so minor in the case of ES5
>> section 10) but have generally maintained the overall structure of the
>> entire document, even when it has appeared to non-optimial or even
>> confusing.
>>
>> I'm now looking at the work to implement the refactoring of the  internal
>> methods in section 8 and I see we are probably going to loose even more of
>> the section number correspondence with previous editions.  This tempts me
>> to seize the moment, abandon the legacy organization, and reorganize in a
>> more logical manner.
>>
>> Here is the new structure that I have in mind, with reference to existing
>> ES5 (section numbers:)
>>
>> Introductory Material
>> Scope (1)
>> Conformance (2)
>> Normative References (3)
>> Overview (4)
>> Notational Conventions(5)
>>
>> The ECMAScript Computational Engine
>> Data Types and Values (8)
>> Commonly used Abstract Operations (9)
>> ECMAScript Execution (10 and possibly parts of 14)
>> [Possibly new material related to module loaders and realms]
>>
>> The ECMAScript Programming Language
>> Source Text (6)
>> Conformance, Error Handling, and Extensions (16)
>> Lexical Tokens (7)
>> Expressions  (11)
>> Statements (12)
>> Functions and Classes (13)
>> Scripts and Modules (14)
>>
>> The ECMAScript Standard Library (15)
>>  [potentially some reordering and reorganization]
>>
>> Annexes
>>
>>
>> What thoughts do people have  about this? Should we go for an improved
>> document organization or should be continue to patch around the current
>> structure, probably forever.  If we do restructure, I would probably do
>> most of the work after we were feature complete and until them, only make
>> incremental changes that make sense that the context of new feature work.
>> But it would be helpful to decide soon which path we are going to take.
>>
>> One of the issue is the correspondence between the spec. organization and
>> the test262 organization.  We already have massive changes changes and the
>> algorithm and algorithm set level that will impact test232, so I'm not sure
>> that the higher level reorg that I'm thinking about would have that much
>> more impact on it.
>>
>> Feedback???
>>
>> Allen
>>
>>
>>
>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: additional Math function

[Yehuda Katz]

Seems like a small surface-area with a large impact on compilers.

At first glance, looks good to me.

Curiosity: Does this overlap with Brendan's work on value objects (i.e.
will it become moot in the face of them)

-- Yehuda Katz
(ph) 718.877.1325
On Nov 2, 2012 12:49 PM, "David Herman"  wrote:

> I'd like to add a Math.imul function for doing 32-bit integer
> multiplication. The use case is for compilers like Emscripten and Mandreel.
> They generate code to emulate machine operations that can be efficiently
> JIT compiled, but they don't currently have a good solution for doing
> integer multiplication. For other operations, like addition, they can use
> the composition of JS's floating-point addition and coercion to int32 via
> bitwise or:
>
> t = (a+b)|0;
>
> But you can't do the same trick with multiplication, because multiplying
> large numbers may lose low bits of precision when it overflows to double.
> So Emscripten has a compiler switch where you can do the fast-but-incorrect
> (a*b)|0 or you can do a slow-but-correct pure-JS multiply, which has to
> split the operation into two multiplications with manual carry. As it turns
> out, multiplication is the only major operation that doesn't have a clear
> implementation pattern with existing JS operators.
>
> The semantics is straightforward:
>
> Math.imul(a, b) === ToInt32((ToUint32(a) x ToUint32(b)) mod 2^32)
>
> In other words, convert the two arguments to 32-bit integers and "do what
> C does." The result is signed, simply as a convention -- signed and
> unsigned integers are isomorphic (ToUint32 and ToInt32 form the bijection
> between them). We could also consider adding Math.umul:
>
> Math.umul(a, b) === ToUint32((ToUint32(a) x ToUint32(b)) mod 2^32)
>
> but it's not strictly necessary; it's equivalent to:
>
> Math.imul(a, b)>>>0
>
> It might be nice to have Math.umul available out of the box, but for
> Emscripten and Mandreel, only one of the two is strictly necessary.
>
> At any rate, this function would be easy for JS engines to implement and
> optimize, and code generators could benefit from it immediately on engines
> that support it.
>
> I believe we could add this to the ES6 extended Math operations, because
> it's extremely simple and well-understood; there's no design necessary.
>
> Dave
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: `free` operator

[Yehuda Katz]

An optimal debugger would show the textual location in the source code
where live references to a particular object were created. Optimally, it
would be possible to get the references during debug mode via the "tooltip"
that comes up when hovering over a variable.

Isaac could then solve his problem trivially by adding a debugger where he
would have called free and look at what other places in the source are
still holding references.

On Fri, Oct 26, 2012 at 12:34 PM, John J Barton  wrote:

> On Fri, Oct 26, 2012 at 11:58 AM, Isaac Schlueter  wrote:
> > So, yes, you can certainly use debugging tools to find which objects
> > are leaking.  But, there are times when you have a program where
> > something is leaking, and you read through the code, and see that
> > there is no possible way that it could be leaking (but it is, as
> > reality sometimes stubbornly refuses to be told what to do.)
> >
> > Use-after-free bugs are not great, but they are relatively easy to
> > track down.  And, in general, a program that crashes when it does
> > something wrong, is handling it exactly right.  Slowly leaking memory
> > is much harder to diagnose, and usually much harder to correct.
> ...
> >
> > Yehuda's "action at a distance" complaint is definitely a valid
> > concern.  However, note that an object can't be freed unless you have
> > a reference to the object.  Thus, any code that would set my reference
> > to undefined could only do so if it was also capable of mutating the
> > object in any other way (adding/removing properties, etc.)
> >
> > So, we already have this:
> >
> > function () {
> > // acquire a ref from some external code
> > // no way of knowing what else is sharing this object
> > var x = func()
> > x.foo = 'bar'
> > // other code...
> > doAnotherThing()
> > // not guaranteed!
> > assert(x.foo === 'bar')
>
> FWIW, Querypoint debugging will be able to tell you "where was x.foo
> changed?".
>
> > }
> >
> > Whenever you have a reference to an object that is shared with some
> > other code, there's the potential for action at a distance.
>
> Seems like other questions we'd like to answer include "where was the
> object refed by 'x' defined?" "Where are other references to that
> object taken?" "Where was any property of 'x' written?" These seem
> feasible.
>
> jjb
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: `free` operator

[Yehuda Katz]

Any proposal that destroys this invariant:

function() {
var x = obj();

// other statements not involving x

x // still defined
}

destroys local reasoning and would almost certainly do more harm than good.

In programs with leaks, the leak is often inside of library code, and
breaking the library's own invariants will cause more confusion, not less,
in many cases.

I shudder to think about bug reports I would receive in my libraries where
someone forced a variable reference I was holding to become undefined or
start throwing if I try to reference it.

-- Yehuda Katz
(ph) 718.877.1325
On Oct 25, 2012 9:25 PM, "John J Barton" 
wrote:

>
> On Oct 25, 2012 8:42 PM, "Domenic Denicola" 
> wrote:
>
> >
> > The new thing this proposal brings to the table is the ability to mark,
> from within your code, exactly what object you're worried about the
> leakiness of. You also get very understandable error messages for
> determining who's using that object. Pouring through the list of retained
> objects, trying to find the one you're concerned about by looking through
> ambiguous short names or via the profiler's deep tree hierarchy, is not
> nearly as straightforward.
>
> But don't you get that by just changing one line to
> var obj = undefined;
> ?
> jjb
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: David’s ProxyMap

[Yehuda Katz]

On Wed, Oct 24, 2012 at 5:16 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> But then why such "encouragement"
> https://brendaneich.com/2012/10/harmony-of-dreams-come-true/ ? ( Proxy
> paragraph )
>
> If __noSuchMethod__ is wrong, what's the point of suggesting a way to
> simulate it through proxies?
>

__noSuchMethod__ isn't the same problem as my concern about invoke-only
traps. In this case, (x = sink.bar).apply(sink) would still hit the
__noSuchMethod__ method.


>
> Moreover, what's the point to mark it wrong if many developers asked for
> it?
>
> I also remember I have written this a while ago:
> http://webreflection.blogspot.com/2011/12/please-give-us-back-nosuchmethod.html
>
> As result I see Tom's implementation with bound callbacks per property and
> a freaking slower runtime every time an API would like a fancy noSuchMethod
> behavior ... just saying :-)
>
> br
>
> On Wed, Oct 24, 2012 at 4:20 PM, Tom Van Cutsem wrote:
>
>> 2012/10/24 Yehuda Katz 
>>
>>>
>>> I'm not sure I understand the benefit of making it easy to develop APIs
>>> where foo.bar() is not roughly equivalent to (x = foo.bar).apply(foo). Am I
>>> misunderstanding something?
>>>
>>
>> No, that's indeed another way of phrasing it. Proxies don't support
>> invoke() in part because we didn't want to encourage such APIs.
>>
>> Cheers,
>> Tom
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>


-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: David’s ProxyMap

[Yehuda Katz]

On Wed, Oct 24, 2012 at 2:56 PM, Tom Van Cutsem  wrote:

> 2012/10/20 Axel Rauschmayer 
>>
>> Currently, proxies make no distinction between a property read access and
>> a method invocation. In my experience, it would be nice if that distinction
>> would be there – if only that one didn’t have to curry for method
>> invocations which must be a performance issue and is a fairly common use
>> case (remotely invoking web services etc.). Now, there are reasons against
>> this and I’m mainly wondering if actually using the new API has changed
>> your or Tom’s mind.
>>
>
> I agree there are use cases for distinguishing method invocations from
> property accesses (remote method calls are one of them -- you'd want to
> distinguish between doing an HTTP GET vs POST). But the new API hasn't
> changed the balance for or against an "invoke" trap. Recall that one of the
> reasons was that an "invoke" trap would lead to invoke-only methods, which
> goes against functional programming patterns in Javascript (e.g. people
> expect array.map(obj.method) to work)
>

I'm not sure I understand the benefit of making it easy to develop APIs
where foo.bar() is not roughly equivalent to (x = foo.bar).apply(foo). Am I
misunderstanding something?


>
> Cheers,
> Tom
>
> _______
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Map.prototype.clear method

[Yehuda Katz]

On Mon, Oct 22, 2012 at 11:32 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

>  On Oct 22, 2012, at 14:28, "Yehuda Katz"  wrote:
>
>  On Mon, Oct 22, 2012 at 11:11 AM, Axel Rauschmayer wrote:
>
>>   What about copying of these new data structures?
>>
>>
>>  It should be possible to initialize a collection via another collection
>> (right?). I prefer copy-constructors to clone() methods.
>>
>
>  That would be fine with me, if supported.
>
>
>
>  Isn't it already specced to work, for Set at least, since it accepts any
> iterable?
>
>  let copy = new Set(original);
>
>  I don't recall offhand if Map accepts an iterable of [key, val] pairs,
> but if it doesn't yet, maybe this provides an argument that it should.
>

Sounds good. Hopefully VMs can optimize the implementation when a Map/Set
is passed in.


-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Map.prototype.clear method

[Yehuda Katz]

On Mon, Oct 22, 2012 at 11:11 AM, Axel Rauschmayer  wrote:

> What about copying of these new data structures?
>
>
> It should be possible to initialize a collection via another collection
> (right?). I prefer copy-constructors to clone() methods.
>

That would be fine with me, if supported.


>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>


-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Map.prototype.clear method

[Yehuda Katz]

A clear method is definitely important for both Map and Set. Our real-world
polyfills have also needed them.

What about copying of these new data structures?

On Mon, Oct 22, 2012 at 10:40 AM, Brendan Eich  wrote:

> +1, no brainer. Thanks for supplying the brain!
>
> /be
>
>
> Jason Orendorff wrote:
>
>> An actual real-world user of ES6 Map (in Firefox-only code) is asking
>> for a .clear() method:
>>
>>   I'm writing a mork reader in JS for mconley's new
>> addressbook (using JS workers, OS.File, and JS Maps !)
>>   one of the operations I need to be able to do amounts to
>> "clear the entire table"
>>   I can't just make it a new map, since I put other
>> properties on the map that I don't want to lose
>>   I'm doing this for now:
>> for (let [tid, value] of this._currentTable)
>>   this._currentTable.delete(tid)**;
>>   why store those extra properties on this._currentTable
>> rather than directly on this?
>>   because I have multiple tables
>>
>> In our current implementation, a builtin Map.prototype.clear method
>> that simply removes all entries from the Map would be quite a bit
>> faster than what jcranmer is currently doing.
>>
>> -j
>> __**_
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>>  __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.assign()

[Yehuda Katz]

On Thu, Oct 18, 2012 at 10:13 AM, Rick Waldron wrote:

>
>
> On Thu, Oct 18, 2012 at 12:59 AM, Dmitry Soshnikov <
> dmitry.soshni...@gmail.com> wrote:
>
>>
>> On Oct 17, 2012, at 9:34 PM, Axel Rauschmayer wrote:
>>
>> Pardon, I missed and cannot find what is Object.assign(...), seems it's
>> not from the latest draft. Is it just defining properties (via
>> Object.defineProperty) on from a source to destination object? Like
>> old-good Object.extend(...)?
>>
>>
>> Explained here:
>> https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-18.md
>>
>>
>> I see, thanks.
>>
>> So, from what I see:
>>
>> 1. Source should not be the one. We should support many of sources to
>> copy all them at once:
>>
>> Object.assign(dest, source1[, source2, ... sourceN])
>>
>
>
> I had originally hoped for this, but we reached consensus
> on Object.assign(dest, source) to allow for a possible descriptor map param.
>
> The pattern you're looking for can be achieved as
>
> [ defaults, options, overrides ].reduce(Object.assign, {});
>
>
>
>>
>> In addition:
>>
>> 2. If the last parameter is boolean, then it's created as
>> includeNonEnumerable:
>>
>> Object.assign(desc, source1[, source2, ... sourceN, includeNonEnumerable);
>>
>
>
> Boolean parameters are a non-starter and would conflict with the desire to
> have an optional third "default descriptor map" parameter.
>

In general, it makes sense to be careful about adding new parameters,
because it prevents useful extensions in the future.


>
>
> Rick
>
>
>>
>> Example;
>>
>> Object.assign({a: 10}, {b: 20}, Object.defineProperties({}, {c: {value:
>> 30}}), true); // {a: 10, b: 20, c: 30}
>>
>> Dmitry
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.assign()

[Yehuda Katz]

The original proposal was for two methods: Object.assign and Object.define.

Object.assign would pave the cowpath of all of the extend() APIs already in
circulation. We thought the precedent of not copying enumerable methods in
those cases was enough reason for Object.assign to have this behavior.

We discussed Object.define for a while, but didn't feel like there was
enough precedent either with a library function like Object.define or with
Object.defineProperty in general to make a decision here. Instead, we would
like the overall JavaScript community to hash out some approaches for
working with the new ES5 property API so we can provide something official
and solid in a future version.

-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Fwd: Fail-fast on non-existing [[Get]]]

[Yehuda Katz]

On Wed, Oct 17, 2012 at 2:55 PM, Brendan Eich  wrote:

> Tom Van Cutsem wrote:
>
>> 2012/10/16 Herby Vojčík mailto:he...@mailbox.sk>>
>>
>>
>> I see two solutions:
>>   - add something to the freeze, seal, preventExtensions family which
>> would set an object to the fail-fast [[Get]] state.
>>   - use a Proxy in the proto chain to trap the unknown [[Get]] and
>> throw early
>>
>> Do you think this needs a solution at all? If yes, which option would
>> you favour?
>>
>>
>> The second option is easy to accomplish but pretty invasive since it
>> requires you to inherit from a particular object. If you have an
>> abstraction that already inherits from something else, you're hosed.
>>
>> Personally, I'm not convinced this is a big enough problem to warrant
>> another "mode" for Javascript objects.
>>
>
> This has come up in TC39, and on this list. Waldemar would like a way (not
> the default) to seal a class so typo'ed member names throw:
>
> https://mail.mozilla.org/**pipermail/es-discuss/2012-May/**022837.html<https://mail.mozilla.org/pipermail/es-discuss/2012-May/022837.html>
>
> However, since then, I recall hearing Waldemar say that the private
> at-name syntax in classes (for him) made the case that maximally minimal
> classes hang together in ES6, without any "const class" or sealed class
> option.
>
> I agree it's not a big enough problem to add a "mode" or anything like
> that. Opt-in by class could be helpful. TypeScript has its optional member
> syntax (?:) and can give warnings. It seems to me this kind of tool-time
> help might be enough.


As I understand it, the idea is to allow gets only after a prior set.

There is a mode in Ruby that warns if you try to access an uninitialized
instance variable, but people consider it annoying because it breaks common
patterns (and in Ruby, unlike JavaScript, ||= is an operator, so it can
skip warning in that case). I suspect that people trying to use objects
that threw when trying to get uninitialized property would be extremely
frustrated, and rightly so.


>
>
> /be
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES accessor usage guidelines (Was: Map/Set.prototype.size)

[Yehuda Katz]

On Wed, Oct 17, 2012 at 11:16 AM, Mark S. Miller  wrote:

> On Tue, Oct 16, 2012 at 4:06 PM, Yehuda Katz  wrote:
>
>> On Tue, Oct 16, 2012 at 6:26 PM, Mark S. Miller wrote:
>>
>>> Getting the comments with a getter seems fine. Appending only the list
>>> of comments with a setter is bad, as it does not resemble storage semantics.
>>
>>
>> Do you mean appending only *to* to list of comments?
>>
>
> Yes.
>
>
>
>>
>> `comment.post = post` has similar semantics to setting a foreign key in a
>> SQL database, which will (obviously) update future requests for "all
>> comments with post_id=post.id". Bidirectionally linked one-to-many
>> relationships are pretty common, and it's desirable for the relationships
>> to remain in sync automatically. I don't think this is the right heuristic
>> for moving to a method.
>>
>> I would expect well written setters to at least be idempotent, and well
>>> written getters to be side effect free.
>>
>>
>> comment.post = post is, of course idempotent. Setting it to the same
>> value as it already has would have no effect.
>>
>
> Good. In light of this, I reread the original post of your example. I had
> misunderstood it.
>
> I strongly agree with those earlier posts saying that we should have some
> well thought out design guidelines for when to use an accessor vs a method,
> and that accessor usage should only be "storage-like". However, now that I
> understand it, I also agree that your example is storage-like enough to my
> eyes that I would like guidelines that permit it as a normal case. I do not
> yet a concrete suggestion other than "getters should be query-only" and
> "setters should be idempotent and not cause 'external' effects (other than
> notifying registered observers)." The key thing about your example is "What
> does external mean?" I don't yet have an answer to offer.
>
> These guidelines are not prescriptive on any external JS community. But we
> need guidelines for APIs designed by TC39 and (hopefully eventually) by w3c.
>

The reason for my examples was just to illustrate that if ES.future had an
API similar to what I presented, I would want it to be an accessor. As a
result, I disagreed with the original proposed guideline.

I like the idempotent requirement, but I'm not sure I agree with the
observer distinction. Especially if the observer is behind the abstraction
boundary, but has observable external side effects (exactly what is
happening in my example), it seems indistinguishable from doing the work in
an accessor.


>
> --
> Cheers,
> --MarkM
>



-- 
Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES accessor usage guidelines (Was: Map/Set.prototype.size)

[Yehuda Katz]

On Tue, Oct 16, 2012 at 6:26 PM, Mark S. Miller  wrote:

> Getting the comments with a getter seems fine. Appending only the list of
> comments with a setter is bad, as it does not resemble storage semantics.


Do you mean appending only *to* to list of comments?

`comment.post = post` has similar semantics to setting a foreign key in a
SQL database, which will (obviously) update future requests for "all
comments with post_id=post.id". Bidirectionally linked one-to-many
relationships are pretty common, and it's desirable for the relationships
to remain in sync automatically. I don't think this is the right heuristic
for moving to a method.

I would expect well written setters to at least be idempotent, and well
> written getters to be side effect free.


comment.post = post is, of course idempotent. Setting it to the same value
as it already has would have no effect.


>
> On Tue, Oct 16, 2012 at 2:36 PM, Tab Atkins Jr. wrote:
>
>> On Tue, Oct 16, 2012 at 2:24 PM, Allen Wirfs-Brock
>>  wrote:
>> > On Oct 16, 2012, at 1:25 PM, Yehuda Katz wrote:
>> >> Agreed. For example:
>> >>
>> >> class Post {
>> >>
>> >> }
>> >>
>> >> class Comment {
>> >>
>> >> }
>> >>
>> >> Post.hasMany("comments");
>> >> Comment.belongsTo("post");
>> >>
>> >> let post = new Post()
>> >> let comment = new Comment();
>> >>
>> >> comment.post = post;
>> >> post.comments //=> [comment]
>> >
>> > A great example of where you should not use an accessor. As a rough
>> > guideline accessors (which are syntactically  models after state
>> attributes)
>> > should be used to set/query  local characteristics of objects.  Methods
>> > should be use for complex computations and for establishing and
>> accessing
>> > complex relationships among objects.  Why? Because experience with
>> complex
>> > object models have shown that you have more
>> > understandable/extensible/maintainable systems when you are careful
>> about
>> > where and how you expose coupling among objects.
>> >
>> > In this case, there is a bi-directional n-to-one relationship being
>> > maintained between objects. Such complex relationships are best modeled
>> > using methods because their require establishing and maintaining the
>> > relationship requires state changes in multiple objects. Expressing the
>> > operation as a method serves as a warning that something more complex
>> than
>> > simply updating some local state is going on.
>> >
>> >
>> >> This is similar to certain DOM APIs, and my expectation of a
>> hypothetical
>> >> version of Ember Data in ES6 would work. I don't think there is
>> anything
>> >> wrong with using an accessor here.
>> >
>> > I don't think anybody hold the DOM up as a stelar example of
>> Object-oriented
>> > design.
>> >
>> > You might not agree with the above guideline, or choose to follow it.
>> > That's fine.  But, what you you propose as an alternative.  What are
>> your
>> > guidelines for choosing to use an accessor rather than a method?   If
>> you
>> > consider you example to be a reflection of "good design" what are the
>> > specific design principles it is following.  Why is that an appropriate
>> > place to use an accessor.
>>
>> I consider Yehuda's example to be a perfectly fine and completely
>> normal place to use an accessor.  *Accessing* the list of comments
>> attached to a post is conceptually a side-effect-free operation.
>> While it can change over time, it only does so due to obvious actions
>> - querying it twice, one immediately after the other, *will* give ===
>> results.
>>
>> *Setting* the attribute may have side-effects, but reasonable ones
>> (setting/unsetting Comments.post or Post.comments on other objects).
>> This is a reasonable thing for a setter to do.
>>
>> I don't see any reason to make these two into methods.
>>
>> ~TJ
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
> Cheers,
> --MarkM
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>

Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES accessor usage guidelines (Was: Map/Set.prototype.size)

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Tue, Oct 16, 2012 at 5:13 PM, Brendan Eich  wrote:

> Yehuda Katz wrote:
>
>> Agreed. For example:
>>
>> class Post {
>>
>> }
>>
>> class Comment {
>>
>> }
>>
>> Post.hasMany("comments");
>> Comment.belongsTo("post");
>>
>> let post = new Post()
>> let comment = new Comment();
>>
>> comment.post = post;
>> post.comments //=> [comment]
>>
>
> I'm with Allen: you shoulda used a method!
>

I feel somewhat strongly that this is an appropriate use of a setter. Using
a method would give the API a static language feel for not enough win. In
the case of a well-defined API with well-understood links between objects,
a setter feels right to me.

In fact, the entire point of Object.observe as an API is to produce
side-effects of setting data properties. Making it asynchronous solves the
programming hazards, but doesn't change the larger philosophical point.
Data bindings and similar systems general produce side effects from
setters, and I am ok with that.


>
> I know, this is all allowed, so it will happen. We're talking "Design
> Rules" here, which the language cannot enforce. But really, too much spooky
> setter action at a distance, even for bidirectionally-linked objects.
>
> /be
>
>>
>> This is similar to certain DOM APIs, and my expectation of a hypothetical
>> version of Ember Data in ES6 would work. I don't think there is anything
>> wrong with using an accessor here.
>>
>> Yehuda Katz
>> (ph) 718.877.1325
>>
>>
>> On Tue, Oct 16, 2012 at 4:12 PM, Erik Arvidsson 
>> > erik.arvidsson@gmail.**com >> wrote:
>>
>> On Mon, Oct 15, 2012 at 12:23 PM, Brendan Eich
>> mailto:bren...@mozilla.org>> wrote:
>> > * get/set accessor may have effects on 'set' (see the DOM) but
>> only on the
>> > receiver object (and unobservably, any children that become
>> garbage, e.g.
>> > when trimming .length on an array-like).
>>
>> That is very limiting, even as a guideline. Any time there are two or
>> more related objects it is very likely that a setter might affect some
>> other object.
>>
>> --
>> erik
>> __**_
>> es-discuss mailing list
>> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org**>
>> 
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>>
>>
>> __**_
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [Fwd: Fail-fast on non-existing [[Get]]]

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Tue, Oct 16, 2012 at 12:51 PM, Herby Vojčík  wrote:

> This did not get to the list, reposting...
>
>  Original Message 
> From: Herby Vojčík 
> Subject: Fail-fast on non-existing [[Get]]
> Date: Fri, 12 Oct 2012 22:42:05 +0200
> To: ECMAScript discussion 
>
> Hello!
>
> I have just looked the video on channel9 between Lars Bak and Anders
> Hejlsberg, and it gave me one idea.
>
> It seems people sometimes worry about (basically because of a typo) that
> they [[Get]] a non-existing property but as it stands, it just returns
> undefined and goes happily on.
>
> I see two solutions:
>   - add something to the freeze, seal, preventExtensions family which
> would set an object to the fail-fast [[Get]] state.
>   - use a Proxy in the proto chain to trap the unknown [[Get]] and
> throw early
>

Using a proxy for your own objects to throw seems reasonable, but see below
for breakage to existing JS patterns. Adding it globally (via
Object.protoype.__proto__) would almost certainly break other JS code on
the page.

Consider this very common pattern:

  obj.foo = obj.foo || bar;

As a matter of practice, lots of JS code relies on the soft-fail behavior,
for good reason, and trying to change that behavior would not likely result
in happiness for consumers of the code that introduced this change.


>
> Do you think this needs a solution at all? If yes, which option would
> you favour?
>
> Herby
>
> P.S.: In the latter case, I see the possibility of putting
> ClosedFormObject (or whatever name) constructor function which would
> have a proxy for a .prototype just one step below Object, and let
> classes that would want to throw on default-undefined-[[Get]] just
> derive from that or its ancestors. Do you think this is minimal enough
> so it can be put directly into language (if the solution does not have
> some flaws which are not apparent to me)?
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES accessor usage guidelines (Was: Map/Set.prototype.size)

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Tue, Oct 16, 2012 at 5:43 PM, Allen Wirfs-Brock wrote:

>
> On Oct 16, 2012, at 2:36 PM, Tab Atkins Jr. wrote:
>
> > On Tue, Oct 16, 2012 at 2:24 PM, Allen Wirfs-Brock
> >>
> >> You might not agree with the above guideline, or choose to follow it.
> >> That's fine.  But, what you you propose as an alternative.  What are
> your
> >> guidelines for choosing to use an accessor rather than a method?   If
> you
> >> consider you example to be a reflection of "good design" what are the
> >> specific design principles it is following.  Why is that an appropriate
> >> place to use an accessor.
> >
> > I consider Yehuda's example to be a perfectly fine and completely
> > normal place to use an accessor.  *Accessing* the list of comments
> > attached to a post is conceptually a side-effect-free operation.
> > While it can change over time, it only does so due to obvious actions
> > - querying it twice, one immediately after the other, *will* give ===
> > results.
> >
> > *Setting* the attribute may have side-effects, but reasonable ones
> > (setting/unsetting Comments.post or Post.comments on other objects).
> > This is a reasonable thing for a setter to do.
> >
> > I don't see any reason to make these two into methods.
>
> So, what are the design guidelines that you would apply leads to these
> being accessors?   When do you use a method?  When do you use an accessor?
>

One possible approach would be to have clear design guidelines for
*getters*, and allow setters with reasonable observable side-effects for
getters that comply. That is the approach I use in my designs.


>
> Allen
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES accessor usage guidelines (Was: Map/Set.prototype.size)

[Yehuda Katz]

Agreed. For example:

class Post {

}

class Comment {

}

Post.hasMany("comments");
Comment.belongsTo("post");

let post = new Post()
let comment = new Comment();

comment.post = post;
post.comments //=> [comment]

This is similar to certain DOM APIs, and my expectation of a hypothetical
version of Ember Data in ES6 would work. I don't think there is anything
wrong with using an accessor here.

Yehuda Katz
(ph) 718.877.1325


On Tue, Oct 16, 2012 at 4:12 PM, Erik Arvidsson wrote:

> On Mon, Oct 15, 2012 at 12:23 PM, Brendan Eich 
> wrote:
> > * get/set accessor may have effects on 'set' (see the DOM) but only on
> the
> > receiver object (and unobservably, any children that become garbage, e.g.
> > when trimming .length on an array-like).
>
> That is very limiting, even as a guideline. Any time there are two or
> more related objects it is very likely that a setter might affect some
> other object.
>
> --
> erik
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modular At-Names

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Tue, Oct 16, 2012 at 11:48 AM, Kevin Smith  wrote:

>
>>> What do you think about the typo problem? Not a major issue?
>>
>
> It's javascript, so I guess I'm used to getting pinched every now and then
> by a little property misspelling.  It's never caused me to miss
> C#/C++/Java/etc.  And it all washes out with proper testing.
>
> It seems orthogonal to me anyway:  if we really want to address member
> name typos, then we want some kind of type system...
>
> (...well, I personally don't want a type system, but you know...)
>

I buy this.


>
> Kevin
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modular At-Names

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Tue, Oct 16, 2012 at 9:45 AM, Kevin Smith  wrote:

> 1. The one-class-per-file pattern is near universal.  When there is more
> than one class, they tend to be in minor supporting roles (like
> exception-type subclasses or simple data structures).
>
> 2. Adding private, protected, etc. declarations to classes adds a good
> deal of baggage to the syntax that many developers will balk at.  I'm not
> sure how to argue this yet, but it just doesn't have the "spirit" of
> javascript.
>

More importantly, it's too easy to mess up.


> 3. "Implicit declaration" is the wrong way to think about modular
> at-names.  At-names, in this design, are simply *namespaced identifiers*.
>  Since modules already define an implicit namespace, it's reasonable and
> convenient to hang these special identifiers off of that namespace.
>

I think this makes sense. What do you think about the typo problem? Not a
major issue?


>
> Kevin
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modules, Concatenation, and Better Solutions

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Tue, Oct 16, 2012 at 9:21 AM, Kevin Smith  wrote:

>
> Just to be sure... Does a get printed only the first time the module A is
>> imported somewhere, or every time?
>>
>
> Only the first time.  But the question here is about nested/inline modules.
>
> Patrick, it must be the other way.  Here's why:
>
> module A {
> export function f() { console.log("A"); }
> }
>
> A.f();
>
> No import required before usage of an inline module.
>

Is that actually true of the current proposal?


> There is a concatenation strategy which will preserve order-of-execution,
> but but without some scope artifacts:
>
> https://gist.github.com/3892979
>
> I'm not saying this is a problem with the current design - just that it
> complicates the concatenation story.
>
> Kevin
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modular At-Names

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Mon, Oct 15, 2012 at 9:46 PM, Allen Wirfs-Brock wrote:

>
> On Oct 15, 2012, at 6:02 PM, Brendan Eich wrote:
>
> > Axel Rauschmayer wrote:
> >> One thing to consider: I would expect IDEs to help with this. For
> example, Eclipse does a pretty good job of letting one forget that one has
> to import things before one can use them.
> >
> > Maybe, but forget IDEs. I think Kevin's point about private @foo, @bar,
> ...; being required in a class using those 25 private members will get old,
> fast.
>
> But if you want private symbols you are going to have to say something
> anyway to distinguish them from regular "public" unique name symbols.
>
> At the last TC39 meeting, I believe we agreed that I should expand the
> private name syntax proposal to include allowing private as a prefix to
> concise methods.  So you could say:
>
> class Foo {
>   private @x() {}
>   private @y() {}
> }
>
> as an alternative to:
>
> class Foo {
>   private @x, @y;
>   @x() {}
>   @y() {}
> }
>
> The prefix is actually more total characters in this case, but if you had
> 25 of them it would probably be easier to manage.
>

In my experiment transforming existing code, that did in fact help, but
there were still a large chunk of private name declarations at the top of
my class.


>
> If you are using private symbols for per instance state you need to be
> explicit about it so it can be referenced byboth method bodies and the
> constructor:
>
> class Foo {
> private @state;
> get state() {return @state};
> set state((value) {@state = value}
> constructor (initialState) {
>this.@state = initialState;
> }
> }
>

Right.


> If at the module level, you are defining a set of "public" symbols that
> will be exported so they can be used as names in public interfaces you need
> to be explicit about the export:
>
> module M {
>export symbol @a, @b, @c, @d
>export class Foo {
>@a() {};
>@b() {}
> ...
>}
> }
>
> So, it seems like the only time when you might get away without explicit
> symbols declarations would be for module local "public" symbols that are
> shared among multiple classes defined within the module.
>

Or, more commonly, symbols that are used in a single class that happens to
be inside a module. Although I can't be sure about this, I expect that a
large number of modules will exist to encapsulate a single class. This is
based on my experience breaking up large JavaScript projects by modules
today, where I rarely have multiple "classes" in a single module.


>
> >
> > The module vs. let scope is also interesting. Allen said the literature
> favored the latter but that wasn't clear from my nowhere-near-comprehensive
> reading.
>
> Presumably that is a large part of our motivation for providing lexically
> scoped let/const/function/class rather than the semi-global function
> scoping.
>
> I believe the main arguments against implicit  declarations are:
>1) they catch misspelling inconsistencies (but not consistent
> misspellings)
>

This is definitely a valid concern. Ruby has a similar problem via instance
variable names (which coincidentally are also `@foo`), and tries to address
this via a warning if an uninitialized instance variable is used. It's not
a particular popular warning in Ruby, fwiw.


>2) they prevent unintended share via coincidental common name selection
>

Again, because I expect that most modules will not contain many classes, I
don't expect this to be a major issue. If the classes in a module are small
enough to justify multiple classes, it will be obvious that the same name
is reused.

That said, my original comments to this proposal addressed exactly this
issue: we might end up seeing people defensively overusing modules to wrap
classes in order to guarantee that private names don't leak out. Upon
further reflection, I don't think this is such a major issue because good
practice will lead to few classes per module anyway.


>
> Allen
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES accessor usage guidelines (Was: Map/Set.prototype.size)

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Mon, Oct 15, 2012 at 5:41 PM, Brendan Eich  wrote:

> Yehuda Katz wrote:
>
>>
>> * get/set accessor may have effects on 'set' (see the DOM) but
>> only on the receiver object (and unobservably, any children that
>> become garbage, e.g. when trimming .length on an array-like).
>>
>>
>> DOM methods like `innerHTML=` seem to violate this particular wording
>> (but perhaps not the spirit?)
>>
>
> Definitely the spirit!
>
> That's one of those "children become garbage" cases, unless I
> misunderstand your point. "The receiver" for .innerHTML includes all
> descendants.


Yeah that makes sense, although the exact side-effects might be more
observable with DOM. Relatedly, are we specifically exempting
Object.observe and DOM Mutation observers from the "observability"
requirement?


>
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modular At-Names

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Mon, Oct 15, 2012 at 4:19 PM, Kevin Smith  wrote:

>
> For the case of importing "37" at-names, I would expect that * imports
>> would take care of it:
>>
>> import * from ModuleDefining37NameInterface;
>>
>
> Oh, come on!
>
> The problem isn't importing the names.  The problem lies in having to
> maintain a nightmarishly long set of declarations which are **completely
> internal to the module**, not exported and not imported.
>

This is essentially the problem I had when I tried to port existing code.
It was especially annoying because it was easy to forget to create and
maintain the declarations.

The more I think about it, the more I think that scoping symbols to modules
would work well. Does that mean symbols are simply disallowed outside of
modules?


>
> Kevin
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES accessor usage guidelines (Was: Map/Set.prototype.size)

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Mon, Oct 15, 2012 at 12:23 PM, Brendan Eich  wrote:

> Allen Wirfs-Brock wrote:
>
>> On Oct 12, 2012, at 2:16 PM, David Herman wrote:
>>
>>  On Oct 12, 2012, at 12:14 PM, Erik 
>> Arvidsson>
>>>  wrote:
>>>
>>>  On Fri, Oct 12, 2012 at 11:16 AM, David Bruant
>>>>  wrote:
>>>>
>>>>> Firefox has implement a Map/Set.prototype.size *method* to query the
>>>>> number
>>>>> of mapping/elements.
>>>>> It's not in the strawman. It appears in the latest draft, though
>>>>> weirdly
>>>>> enough Map.prototype.size is a function with an unused argument.
>>>>> What about making it an getter instead of a function? I guess we also
>>>>> don't
>>>>> need the extra parens to request for Map#keys, Map#values, Map#items.
>>>>>
>>>> For keys, values and items I think they are cleaner as methods since
>>>> they return a new iterator every time.
>>>>
>>> Agreed.
>>>
>>> Dave
>>>
>>>
>> I buy making Map/Set size an accessor.  This will be the first such
>> property in the ES specification and it would be good to have some
>> guidelines to help us make consistent decisions about using accessors in
>> the future.
>>
>> Erik and Tab floated a couple reasons why items/keys/values should not be
>> accessors.
>>
>> Does anybody want to  take a crack at writing up a complete set of design
>> rules for when a built-in property should/shouldn't be defined as an
>> accessor?
>>
>
> Simpler is better. Tab, Arv, and others hit the big one. Here's a first
> cut:
>
> * get-only accessor for non-writable property must be idempotent,
> effect-free.
>
> * get/set accessor may have effects on 'set' (see the DOM) but only on the
> receiver object (and unobservably, any children that become garbage, e.g.
> when trimming .length on an array-like).
>

DOM methods like `innerHTML=` seem to violate this particular wording (but
perhaps not the spirit?)


> * get/set accessors should reflect as such. This means Array.length gets a
> legacy dispensation, and __proto__ needs poisoning.
>
> * anything else is a method.
>
> /be
>
> __**_
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modular At-Names

[Yehuda Katz]

During the last TC39, I converted a large Ember class (Ember.View) to
ES6-style classes with private names.

I ended up needing a huge number of explicit declarations, which was very
annoying to me. At the time, I proposed making classes an implicit symbol
namespace. That didn't work because it would prevent using private names in
imperative code. Because the current class definition forces the use of
imperative code for many constructs (including static methods), this was
fatal.

This approach is interesting, because it implies a 1:1 mapping between a
"privacy context" and modules. At first glance, this seems plausible, but I
don't have enough (any?) experience using ES6 modules in a real-world
context to know whether this would force the creation of many extra modules
simply to force a new namespace.

Is there any precedent we can lean on here?

Yehuda Katz
(ph) 718.877.1325


On Fri, Oct 12, 2012 at 10:51 PM, Kevin Smith  wrote:

>
> Yes, although I don't take the "private, who needs it?" attitude as easily
>> as you do. Not saying it's wrong, but I'm not 100% convinced yet.
>>
>
> In a way I'm posing a challenge - I think it will be an interesting debate
> to have.
>
> Doesn't this have the same problem you were arguing against in your
>> previous message, that if you want to import 37 names, you have to name
>> them all individually?
>>
>
> Sure, if we were inclined to import 37 names, but I don't think that will
> be the pattern.  Look at current usage of "underscored" property names.
>  Their usage is mostly confined to a single site (usually a class).
>  Only occasionally will you find an underscored property name whose
> semantic origin is non-local (usually in class hierarchies).
>
> Kevin
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: arrows and a proposed softCall

[Yehuda Katz]

To be honest, I was mostly thinking about this feature from a jQuery
transition perspective.

Right now, callbacks to methods like `each` in jQuery expect to receive a
`this` binding for the current element in the iteration.

For example, in the case of `each`, the call signature looks like this:

jQuery.each(someArray, function(i, item) {
  // this and item are the items in the Array
  // i is the index
});

It's too late for jQuery to fix the order now. However, in the face of
arrows or bound functions, we probably could detect a user intent to use
`this` for their own purposes and use that as a signal to change the order.

jQuery.each = function(array, callback) {
  for (var i=0, l=array.length; i wrote:

>
>
> On Mon, Jun 4, 2012 at 9:54 AM, Brendan Eich  wrote:
>
>> You mean you still propose that (=> 42).call({}) should throw, but
>> (function () { return 42; }).call({}) should not?
>>
>> Sorry, this isn't a principled response. There should be no difference in
>> result between those two cases.
>>
>>
> I disagree. You yourself said "so are you looking for an isBound predicate
> just to throw an error? I'm not saying that is a non-goal". The principal
> is let the user know they are trying to set |this| in a hard bound
> function. The level of introspection required to go the extra mile and look
> for |this| usage seems neither desirable or useful. If my function doen't
> reference |this| then I don't care if |this| is modifiable.
>
> However I thought we had some agreement that -> was a valid goal. In which
> case this error throwing stuff is less important (to me at least)
>
>
>
>> Apart from principles, it seems to me you think arrows will be such sweet
>> sugar that people will make mistakes using this-sensitive API contracts,
>> where long-but-this-insensitve-**functions would not be so misused.
>>
>> To demonstrate this we need to see some evidence. It's not enough to
>> worry, or to hypothesize unfixed code shipped and failing at scale due to
>> failure to test arrow function misuse on the part of developers.
>
>
> I'm the first to admit I have no hard evidence, only heresay
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

arrows and a proposed softCall

[Yehuda Katz]

I've been thinking a lot about the proposed arrows and its affect on `this`.

To start, I'm a worried that `call` and `apply` don't "work" on arrow
function. This is of course the correct behavior for jQuery-like use-cases,
but the proposed semantics interfere with more intentional uses of `call`
and `apply`.

I'd like to propose the following:

* `call` and `apply` modify `this` in an arrow function
* `softCall` and `softApply` do not modify `this` in arrow functions, but
do modify `this` in regular functions

This would allow libraries like jQuery to continue providing advisory
`this` bindings without interfering with intentional modifications to the
`this` binding. (jQuery could do `softCall = Function.prototype.softCall ||
Function.prototype.call` to quickly "polyfill").

I'm not sure if this makes sense, but something about breaking `call` and
`apply` doesn't sit right with me.

Thoughs?

Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: set.delete method name

[Yehuda Katz]

Let me explain my use-case a bit more. Ember exposes an Ember.Map class
that downstream users (the framework, but also app developers) can use when
they want maps with arbitrary keys. I explained the implementation a bit
upthread.

Ideally, I would like to be able to do something like Ember.Map = Map if
ES6 maps are available, since we fashioned our map API intentionally after
the ES6 API.

However, this means that all downstream users would need to use ['delete']
something that is sufficiently weird and confusing to new developers that
we always avoid it.

It occurs to me that if Maps are available, so are proxies, but I'm not
sure I want to start using proxies as a blunt force instrument.

Sent from my Windows Phone
--
From: Mark S. Miller
Sent: 2/28/2012 11:54 AM
To: Adam Shannon
Cc: Yehuda Katz; es-discuss
Subject: Re: set.delete method name

I appreciate the feedback, but I do not understand the rationale. Is it
just to avoid needing to say

map['delete'](key)

when supporting old browsers without an ES5->ES3 translation step? If there
is no other downside, I'm inclined to stick with "delete".


On Tue, Feb 28, 2012 at 11:49 AM, Adam Shannon  wrote:

> I agree that it should be named "remove" rather than delete.
>
>
> On Tuesday, February 28, 2012, Yehuda Katz wrote:
>
>> Just catching up on this discussion. I should point out that this problem
>> applies to Map and possibly other collections as well.
>>
>> Speaking as someone who is looking to use these features today, I hit
>> this problem immediately. Ember.js already has a Map; we can reliably
>> generate a unique id for any object (by stashing it on the object; ok for
>> our cases), and have a reliable way to generate guids for non-Objects.
>>
>> Ideally, we'd like to be able to say something like: `if(typeof Map !==
>> "undefined") { Ember.Map = Map; }` (although we'd probably do more checks
>> because shims in general have worse performance characteristics).
>>
>> Unfortunately, because of the `delete` problem, we cannot do this.
>> Because we are unwilling to monkey-patch Map directly, we will have to
>> create a shim object that delegates to the Map.
>>
>>  I'm sympathetic to the "let's not make choices based on old broken
>> browsers", but let's be fair here. The name `remove` is perfectly clear. In
>> five years, nobody is going to think twice about that API, and web
>> developers won't think twice about it today. Using a clear name that also
>> happens not to run afoul of older browsers for shim purposes isn't caving
>> to the past: it's being pragmatic about helping people adopt a new feature
>> with very little cost.
>>
>> Yehuda Katz
>> (ph) 718.877.1325
>>
>
>
> --
> Adam Shannon
> Developer
> University of Northern Iowa
> Sophomore -- Computer Science B.S. & Mathematics
> http://ashannon.us
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Array extras functionality for iterators

[Yehuda Katz]

Catching up on this discussion.

Personally, I'd like to see us come to quick consensus on `forEach` for
collections, because without something like `forEach`, it's impossible to
implement useful versions of these collections in user-space in browsers
that do not implement for-of.

Indeed, the current browsers that implement Map and Set do not implement
for-of, which means that even though browsers implement the collections
(and Mozilla has for a bit now), they are not very useful because they
cannot be iterated over. Had `forEach` been part of the initial spec, I
would be using them today.

One last thing: `forEach` on `Map` should probably pass the key and value
to the function.

Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: set.delete method name

[Yehuda Katz]

Just catching up on this discussion. I should point out that this problem
applies to Map and possibly other collections as well.

Speaking as someone who is looking to use these features today, I hit this
problem immediately. Ember.js already has a Map; we can reliably generate a
unique id for any object (by stashing it on the object; ok for our cases),
and have a reliable way to generate guids for non-Objects.

Ideally, we'd like to be able to say something like: `if(typeof Map !==
"undefined") { Ember.Map = Map; }` (although we'd probably do more checks
because shims in general have worse performance characteristics).

Unfortunately, because of the `delete` problem, we cannot do this. Because
we are unwilling to monkey-patch Map directly, we will have to create a
shim object that delegates to the Map.

I'm sympathetic to the "let's not make choices based on old broken
browsers", but let's be fair here. The name `remove` is perfectly clear. In
five years, nobody is going to think twice about that API, and web
developers won't think twice about it today. Using a clear name that also
happens not to run afoul of older browsers for shim purposes isn't caving
to the past: it's being pragmatic about helping people adopt a new feature
with very little cost.

Yehuda Katz
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: array like objects

[Yehuda Katz]

Your strawman would support:

{0: "strawman", length: 0}

A better definition might be:

   o is an array like object if o[[Get]]('length') returns a Number one
greater than the largest numeric property, or 0 if no numeric properties
exist.

Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325


On Mon, Dec 7, 2009 at 5:33 PM, Mike Samuel  wrote:

> It occurred to me after looking at the proxy strawman that it might
> help to nail down what "array-like" means in future drafts.  It isn't
> directly related to the proxy stuff though so I thought I'd start a
> separate thread.
>
> I've seen quite a bit of library code that does something like
>   if (isArrayLike(input)) {
> // iterate over properties [0,length) in increasing order
>   } else {
> // Iterate over key value pairs
>   }
> but different libraries defined array-like in different ways.
> Some ways I've seen:
>(1) input instanceof Array
>(2) Object.prototype.toString(input) === '[object Array]'
>(3) input.length === (input.length >> 0)
> etc.
>
> The common thread with array like objects is that they are meant to be
> iterated over in series.
> It might simplify library code and reduce confusion among clients of
> these libraries if there is some consistent definition of series-ness.
> This committee might want to get involved since it could affect
> discussions on a few topics:
>   (1) key iteration order
>   (2) generators/iterators
>   (3) catchall proposals
>   (4) type systems
>
> One strawman definition for an array like object:
>o is an array like object if o[[Get]]('length') returns a valid
> array index or one greater than the largest valid array index.
>
> The need to distinguish between the two in library code could be
> mooted if for (in) on arrays iterated over the array index properties
> of arrays in numeric oder order first, followed by other properties in
> insertion order, and host objects like NodeCollections followed suit.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Web IDL Garden Hose

[Yehuda Katz]

I meant "actually written". Being able to see actual code that implemented
pieces of the IDL in ES would make some of the more complex interactions
more obvious (I suspect).
-- Yehuda

On Tue, Sep 29, 2009 at 3:28 AM, Maciej Stachowiak  wrote:

>
> On Sep 28, 2009, at 11:34 PM, Yehuda Katz wrote:
>
>  It would be pretty nice if the language bindings of WebIDL were
>> available in pure ES, where possible. To some degree, that is not
>> currently possible (in ES3), but it will be a lot better in ES5. I
>> think it might actually be possible to get a large degree of
>> completion just using the JavaScript available in Spidermonkey.
>>
>
> What do you mean by "available"? A lot of Web IDL interfaces are actually
> implementable in ES5 (at least the interface part - not necessarily the
> underlying functionality without relying on APIs outside the language).
> Using ES5 as the reference baseline would help make this more clear perhaps.
>
>  - Maciej
>
>
>
>> This might also be a useful step in the direction that I was hoping
>> for in some earlier postings.
>>
>> -- Yehuda
>>
>> On Mon, Sep 28, 2009 at 11:22 PM, Maciej Stachowiak 
>> wrote:
>>
>>>
>>> On Sep 28, 2009, at 10:12 AM, Allen Wirfs-Brock wrote:
>>>
>>>  -Original Message-
>>>>> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
>>>>> boun...@mozilla.org] On Behalf Of Robin Berjon
>>>>>
>>>>>>
>>>>>> There is no old version.
>>>>>>
>>>>>
>>>>> Right, this is v1. What previous W3C API specifications had relied on
>>>>> was either OMG IDL, or the common lore understanding that people were
>>>>> familiar with this way of expressing APIs, so they'd get it right.
>>>>> We're trying to do a bit better than that.
>>>>>
>>>>>
>>>> The primary concern of TC39 members is with the WebIDL ECMAScript
>>>> bindings.  I haven't yet heard any particular concerns from TC9 about
>>>> WebIDL
>>>> as an abstract language independent interface specification language.
>>>> Since
>>>> W3C seems committed to defining language independent APIs, I would think
>>>> that the language independent portion of the WebIDL spec. would be the
>>>> only
>>>> possible blocker to other new specs.
>>>>
>>>> It seems like this might be a good reason to decouple the specification
>>>> of
>>>> the actual WebIDL language from the specification of any of its language
>>>> bindings.
>>>>
>>>
>>> Defining the Web IDL syntax without defining any language bindings would
>>> not
>>> be very useful:
>>>
>>> 1) The syntax is to a large extent designed around being able to express
>>> the
>>> right behavior for language bindings, particularly ECMAScript bindings.
>>> So
>>> we can't really lock it down without knowing that it can express the
>>> needed
>>> behavior in the bindings, which requires the bindings to be done.
>>>
>>> 2) To actually implement any spec using Web IDL, implementors need at
>>> least
>>> one language binding, and most implementors will consider an ECMAScript
>>> binding to be essential. Without the bindings being defined, it will not
>>> be
>>> possible to build sound test suites for the specs using Web IDL.
>>>
>>> 3) The whole point of Web IDL was to define how DOM and related Web APIs
>>> map
>>> to languages, and especially ECMAScript. Previous specs used OMG IDL
>>> where
>>> the mapping was not formally defined, and implementors had to read
>>> between
>>> the lines. Removing language bindings from Web IDL would return us to the
>>> same bad old state, thus missing the point of doing Web IDL in the first
>>> place.
>>>
>>> Regards,
>>> Maciej
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>>
>> --
>> Yehuda Katz
>> Developer | Engine Yard
>> (ph) 718.877.1325
>>
>>
>


-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Web IDL Garden Hose

[Yehuda Katz]

It would be pretty nice if the language bindings of WebIDL were
available in pure ES, where possible. To some degree, that is not
currently possible (in ES3), but it will be a lot better in ES5. I
think it might actually be possible to get a large degree of
completion just using the JavaScript available in Spidermonkey.

This might also be a useful step in the direction that I was hoping
for in some earlier postings.

-- Yehuda

On Mon, Sep 28, 2009 at 11:22 PM, Maciej Stachowiak  wrote:
>
> On Sep 28, 2009, at 10:12 AM, Allen Wirfs-Brock wrote:
>
>>> -Original Message-
>>> From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
>>> boun...@mozilla.org] On Behalf Of Robin Berjon
>>>>
>>>> There is no old version.
>>>
>>> Right, this is v1. What previous W3C API specifications had relied on
>>> was either OMG IDL, or the common lore understanding that people were
>>> familiar with this way of expressing APIs, so they'd get it right.
>>> We're trying to do a bit better than that.
>>>
>>
>> The primary concern of TC39 members is with the WebIDL ECMAScript
>> bindings.  I haven't yet heard any particular concerns from TC9 about WebIDL
>> as an abstract language independent interface specification language. Since
>> W3C seems committed to defining language independent APIs, I would think
>> that the language independent portion of the WebIDL spec. would be the only
>> possible blocker to other new specs.
>>
>> It seems like this might be a good reason to decouple the specification of
>> the actual WebIDL language from the specification of any of its language
>> bindings.
>
> Defining the Web IDL syntax without defining any language bindings would not
> be very useful:
>
> 1) The syntax is to a large extent designed around being able to express the
> right behavior for language bindings, particularly ECMAScript bindings. So
> we can't really lock it down without knowing that it can express the needed
> behavior in the bindings, which requires the bindings to be done.
>
> 2) To actually implement any spec using Web IDL, implementors need at least
> one language binding, and most implementors will consider an ECMAScript
> binding to be essential. Without the bindings being defined, it will not be
> possible to build sound test suites for the specs using Web IDL.
>
> 3) The whole point of Web IDL was to define how DOM and related Web APIs map
> to languages, and especially ECMAScript. Previous specs used OMG IDL where
> the mapping was not formally defined, and implementors had to read between
> the lines. Removing language bindings from Web IDL would return us to the
> same bad old state, thus missing the point of doing Web IDL in the first
> place.
>
> Regards,
> Maciej
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: WebIDL

[Yehuda Katz]

On Fri, Sep 25, 2009 at 11:38 PM, Brendan Eich  wrote:
>> I did not single out Replaceable in my efforts to understand.
>
> Sure, but it is certainly odd and I wanted to recount some of the history,
> just so you'd know not to over-attend to it. ;-)

Ha. Maybe it would be worth putting a note in HTML5. "[Replaceable] is
a quirk of history. Do not over-attend to it".

>
> WebIDL comes from OMG IDL, much of the precedent is documented in various
> online sites, CORBA books, etc. It's not all that strange or bad, just a bit
> "'90s big OOP system" in flavor.
>
> To understand it all takes a while, and Maciej allowed as how some of it
> could be cut without harm. Maybe we should start there.

Do we disagree that it is a worthy goal to have a specification that
can be understood without having to take a while? I certainly
understand the utility in using something with precedent like IDL (for
implementors). Perhaps the IDL version could be part of an addendum,
and something with less historical and conceptual baggage be used
inline? Or is that too much work?

>
> /be
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

[Yehuda Katz]

On Fri, Sep 25, 2009 at 11:28 PM, Brendan Eich  wrote:
> On Sep 25, 2009, at 11:20 PM, Yehuda Katz wrote:
>
>> On Fri, Sep 25, 2009 at 11:15 PM, Brendan Eich 
>> wrote:
>>>
>>> On Sep 25, 2009, at 9:38 PM, Yehuda Katz wrote:
>>>
>>> Another way to put my earlier concern
>>>
>>> Sorry, what earlier concern? You are replying to my reply to Doug
>>> Schepers
>>> on a sub-thread where I didn't see a message from you.
>>
>> So confusing! So many messages!
>
> No, you just replied off-topic and rehashed an issue that we all agree needs
> fixing, seemingly as if I had implied that it wasn't an issue. Although the
> generous citations of my reply to Doug Schepers that you included of course
> implied nothing of the kind.
>
> Why did you do that?

I failed? There are about 100 messages on this topic that I'm reading
and trying to digest. There's a whole lot of history involved. In the
end, I can only speak for myself, and I can say that I'm personally
having a lot of trouble trying to piece things together by looking at
the specifications.

>
> [big snip]
>
>> My point is that understanding the semantics of the language as
>> implemented by browser vendors is not possible by reading the language
>> spec. These is not some hypothetical extension, but a mandatory way
>> that ECMAScript implemented for the web must behave.
>
> Well, duh.
>
> We seem to agree, perhaps vehemently :-/.
>
> One last time, for the record: it is a bug in ES specs that you can't follow
> th
> The whole point of bothering the HTML WG, public-webapps, and es-discuss
> about collaboration between Ecma and W3C folks has been to fill gaps between
> specs and reality. We had some false starts in my view (like trying to move
> ES WebIDL bindings to Ecma up front, or ever). But the issues laid out in
> Sam's original cross-post were exactly the "gaps" between ES specs, HTML5
> ones, and browser implementations. At last some of the gaps are filled in
> HTML5 but not in ways that can be injected directly into ES specs.

I'm actually being a bit more radical than you are (perhaps naïvely).
I am personally finding WebIDL to be a blocker to understanding.
That's because it's another spec that interacts with two other (fairly
complex) specs in unpredictable and context-sensitive ways.

> We should fix the ES specs, and make whatever changes follow to the HTML5
> specs. And maybe use WebIDL to constrain "host objects". All this has been
> said on the thread already. Were you not reading the messages I was?

I think I saw that in the thread ;)

Like I said, my problem is that the interaction between the three
specs is making it nearly impossible for a casual reader to understand
what's going on. I strongly apologize for not being clearer about
that; I'm only starting to fully understand the source of my own
confusion.

>
> /be
>
>

-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: WebIDL

[Yehuda Katz]

On Fri, Sep 25, 2009 at 11:28 PM, Brendan Eich  wrote:
> On Sep 25, 2009, at 11:05 PM, Yehuda Katz wrote:
>
>>> In the ES binding, the properties for these [Replaceable] attributes are
>>> effectively writable, but assigning to them breaks their link to the
>>> original attribute.  The assignment doesn’t perform any conversion from
>>> the ES value to the IDL type, either.  In other language bindings you
>>> would want these properties to behave like normal readonly attributes,
>>> e.g. in Java by having only a setter method.
>>
>> So this extension effectively converts a readonly attribute to a
>> writable one? Talk about confusing. And this isn't true about the same
>> attribute in non-ES contexts?!
>
> Please hold your fire. [Replaceable] was added in the 90s when Netscape 4
> and IE4 tried to evolve the DOM by adding properties to the global (window)
> object, and found the common names intended were already in use. It's a
> mistake to try to add common names, but try we did (both Netscape and
> Microsoft), with the hack of allowing the name to be preempted by content.
> Only if not "replaced" would the Netscape code actually reify the new
> property on demand. I'm not sure how IE did it.

Understood. I don't have the benefit of the history here
(unfortunately), just the specs as they stand today.

>
> This is an ongoing issue. Adding JSON (from json2.js) to ES5 involved some
> pain, due to other implementations of a JSON codec using the same name but
> different method names in the top-level JSON object. But it didn't require
> anything like [Replaceable] to sort out.
>
> We're stuck with [Replaceable], although like any sunk cost it is not
> cost-free and we could reengineer it. But what's the gain? Pointing out the
> silly way it makes readonly properties low-integrity is not helpful. Yes,
> you can "replace" (or preempt, I prefer) such properties with your own vars
> or functions in content. That was the way it worked in the 4th generation
> browsers. Why reengineer this minor piece of WebIDL now?

WebIDL, taken as a whole, make it very difficult for someone new to
the spec(s) to understand what's going on. I started, like a
reasonable person, by looking at the Window object. When looking at
it, I encountered a number of somewhat confusing constructs, like this
one. It is possible to have a long conversation where all of the
details are hashed out, but the reality is that the specs cannot be
easily understood without such a hashing.

I did not single out Replaceable in my efforts to understand.

>
> /be



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

[Yehuda Katz]

On Fri, Sep 25, 2009 at 11:15 PM, Brendan Eich  wrote:
> On Sep 25, 2009, at 9:38 PM, Yehuda Katz wrote:
>
> Another way to put my earlier concern
>
> Sorry, what earlier concern? You are replying to my reply to Doug Schepers
> on a sub-thread where I didn't see a message from you.

So confusing! So many messages!

>
> is: It's impossible to write a
> conforming JS engine that browsers will want to use by only following
> the ES spec - since there's additional, un-speced, behavior that isn't
> in ES that is necessary in order to construct a browser's DOM.
>
> This is a problem to fix. No one is arguing that it's not a problem. What's
> the real topic?

The *real* problem is that for people who are not implementing this
stuff, it is extremely difficult to track down and piece together all
of the semantics. It would seem reasonable to go look at the
ECMAScript spec to understand ECMAScript semantics, but as it turns
out, it's also necessary to read HTML5 and WebIDL. I have no objection
to needing to read the HTML5 spec to understand how the *DOM* works. I
object to having to read HTML5 to understand how ECMAScript works
(which is currently necessary).

> Consider the following scenario: I write an ECMAScript engine that is
> significantly faster than any existing engine by simply following the
> ECMAScript spec. A browser maker then wishes to use this engine. This
> would be impossible without adding additional (hidden) features to the
> engine to support the DOM. There is nothing in the ECMAScript spec
> that requires the ability (at the very least) to add native extensions
> with arbitrary behavior to the engine.
>
> The ES spec allows extensions, but it cannot require them without the
> extensions being no longer extensions in any sense, rather as specified
> parts of the normative core language. Again I don't know what your point
> here is.

My point is that understanding the semantics of the language as
implemented by browser vendors is not possible by reading the language
spec. These is not some hypothetical extension, but a mandatory way
that ECMAScript implemented for the web must behave.

> Is this a requirement ECMA is comfortable with?
>
> What requirement? Your scenario? I have no idea where it came from, but it
> doesn't follow from anything you cited (cited again below).
> If you mean we need to specify multiple globals, split windows, execution
> model, etc. -- that's what I've been saying on the main thread since the
> first message, and what Sam's transcription of a private message from me
> tried to say.
> Still not sure what your point is,
> /be

I'm sorry.

>
> -- Yehuda
>
> On Thu, Sep 24, 2009 at 3:19 PM, Brendan Eich  wrote:
>
> On Sep 24, 2009, at 2:43 PM, Doug Schepers wrote:
>
> [much appreciated information snipped -- thanks!]
>
> I really don't see how the review process and accountability could be much
>
> more open for the development of Web IDL elsewhere, nor is the burden on
>
> reviewers that large... it would simply be one more low-traffic mailing
>
> list.  Are there other barriers you see?
>
> I alluded to employers who are not currently paying W3C members not wanting
>
> their employees participating, even individually. I'll let one notable
>
> example that I know of speak for himself.
>
> The "mailing list as firehose" problem can be solved with enough work, but
>
> with two standards groups there is always greater risk of conflict, and just
>
> competition for attention. Two lists is simply one more list than one list
>
> to keep up with.
>
> This is a price of collaboration at wider scale, so don't let me stand in
>
> the way, since I've been explicit about being in favor of collaboration.
>
> W3C and Ecma both have transparency issues, but I don't expect those to be
>
> fixed easily. I mentioned them ("People in dark-glass houses ... [should not
>
> throw stones]") in reply to Maciej asserting greater openness on one side.
>
> Again this is not a "barrier" I'm trying to take down right now.
>
> /be
>
> ___
>
> es-discuss mailing list
>
> es-discuss@mozilla.org
>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
> --
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: WebIDL

[Yehuda Katz]

Thanks for your responses. They are very useful. First of all, the
length of this response (and the explanations themselves) speak to the
difficulty casual spec readers have in understanding this syntax. More
specific responses inline.

On Fri, Sep 25, 2009 at 10:29 PM, Cameron McCormack  wrote:
> Hi Yehuda.
>
> Yehuda Katz:
>> 1. There are a number of ECMAScript-specific extensions here that have
>> obscure names and non-obvious behavior. For instance, understanding
>> "[Replaceable] readonly" is non-trivial. In fact, "[Replaceable]
>> readonly" has somewhat confusing semantics, in that the attribute is
>> not really readonly at all. The readonly definition is "An object that
>> implements the interface on which a read only attribute is defined
>> will not allow assignment to that attribute", while [Replaceable]
>> means "If the [Replaceable] extended attribute appears on a read only
>> attribute, it indicates that setting the corresponding property on the
>> host object will result in that property being removed and a new one
>> created that is unrelated to the attribute, and which has the value
>> being assigned".
>>
>> In fact, aren't these properties not readonly at all. Instead, doesn't
>> this idiom mean that the property is linked to some invisible
>> attribute that is also used by other methods? Isn't that a more useful
>> thing to express?
>
> In the ES binding, the properties for these [Replaceable] attributes are
> effectively writable, but assigning to them breaks their link to the
> original attribute.  The assignment doesn’t perform any conversion from
> the ES value to the IDL type, either.  In other language bindings you
> would want these properties to behave like normal readonly attributes,
> e.g. in Java by having only a setter method.

So this extension effectively converts a readonly attribute to a
writable one? Talk about confusing. And this isn't true about the same
attribute in non-ES contexts?!

> Note that, while it may not be clear from the text, section 3 of Web IDL
> only makes requirements of IDL fragments, not on language bindings for
> any interfaces.  The talk about not allowing assignment to the attribute
> is a true description of both the ES and the Java bindings: the IDL
> attribute itself isn’t writable, but [Replaceable] indicates that the ES
> property that reflects that attribute is writable (and does something
> non-obvious).

It wasn't clear from the text, but now that I understand it, it
doesn't help much. "An object that implements the interface on which a
read only attribute is defined will not allow assignment to that
attribute. It is language binding specific whether assignment is
simply disallowed by the language, ignored or an exception is thrown."
It's unclear to me how this is not specifying a requirement on the
language binding. This whole thing is extremely confusing.

> I wonder if for [Replaceable] and other similar hacks for legacy DOM
> behaviour we should state that they SHOULD NOT be used.

If something is in WebIDL purely as a description for known legacy
behavior, it would be helpful if the case(s) in question were called
out in the spec, and use of the syntax was disallowed for other cases.

>> 2. Can't we have more useful defaults here? For instance, why can't
>>
>> >  readonly attribute WindowProxy parent;
>> >  readonly attribute Element frameElement;
>> >  WindowProxy open(in optional DOMString url, in optional DOMString target, 
>> > in optional DOMString features, in optional DOMString replace);
>>
>> be identical to
>>
>> >  readonly WindowProxy parent;
>> >  readonly Element frameElement;
>> >  WindowProxy open(optional DOMString url, optional DOMString target, 
>> > optional DOMString features, optional DOMString replace);
>
> We could make the syntax for attributes less similar to OMG IDL’s by
> dropping the “attribute” keyword, but given that people are familiar
> with this syntax (pre-Web IDL) and that implementations use IDL files
> with this syntax as part of their builds, I’m not sure it’s worth it.

I'll put it another way: what's the utility of this additional word.
In my opinion, if a word appears in the HTML5 specification, it should
be there for a reason. If it is not, it just adds additional confusion
for readers of the spec.

>
> Although, we did drop the requirement for the “in” keyword:
>
>  The "in" keyword used in the declaration of each argument is optional.
>  No other types of arguments (such as out or in-out arguments) can be
>  specified with Web IDL.
>    — http://dev.w3.org/2006/webapi/WebIDL/#idl-opera

Re: arguments.callee in Harmony

[Yehuda Katz]

Or never? I can't shake the feeling that strict mode is a sop to
people with minority opinions, but which will end up shaping the
future of ES going forward.

-- Yehuda

On Fri, Sep 25, 2009 at 9:01 PM, Mark S. Miller  wrote:
> On Fri, Sep 25, 2009 at 2:24 PM, Charles Jolley  wrote:
>> PS. Is there an official way to detect that I am running code in ES5 strict 
>> mode?  I can't find it in the spec.
>
> To summarize:
>
> A conventional pattern for testing "Am I in >= ES5 strict mode?" is
>
>    if (function(){return this;}()) {
>      // I am not in strict mode
>    } else {
>      // I am in strict mode, and therefore in >= ES5
>    }
>
> A conventional pattern for testing "Am I in >= ES5?" is
>
>    if (function(){"use strict";return this;}()) {
>      // I am in < ES5
>    } else {
>      // I am in >= ES5
>    }
>
> For these to work, it is important that browser makers rolling out ES5
> features incrementally not cause the ES5-sides of these tests to
> succeed until their ES5 system is complete. In other words, much as it
> pains me to suggest this, please implement strict mode last.
>
>
> --
>    Cheers,
>    --MarkM
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

[Yehuda Katz]

Another way to put my earlier concern is: It's impossible to write a
conforming JS engine that browsers will want to use by only following
the ES spec - since there's additional, un-speced, behavior that isn't
in ES that is necessary in order to construct a browser's DOM.

Consider the following scenario: I write an ECMAScript engine that is
significantly faster than any existing engine by simply following the
ECMAScript spec. A browser maker then wishes to use this engine. This
would be impossible without adding additional (hidden) features to the
engine to support the DOM. There is nothing in the ECMAScript spec
that requires the ability (at the very least) to add native extensions
with arbitrary behavior to the engine.

Is this a requirement ECMA is comfortable with?

-- Yehuda

On Thu, Sep 24, 2009 at 3:19 PM, Brendan Eich  wrote:
> On Sep 24, 2009, at 2:43 PM, Doug Schepers wrote:
>
> [much appreciated information snipped -- thanks!]
>
>> I really don't see how the review process and accountability could be much
>> more open for the development of Web IDL elsewhere, nor is the burden on
>> reviewers that large... it would simply be one more low-traffic mailing
>> list.  Are there other barriers you see?
>
> I alluded to employers who are not currently paying W3C members not wanting
> their employees participating, even individually. I'll let one notable
> example that I know of speak for himself.
>
> The "mailing list as firehose" problem can be solved with enough work, but
> with two standards groups there is always greater risk of conflict, and just
> competition for attention. Two lists is simply one more list than one list
> to keep up with.
>
> This is a price of collaboration at wider scale, so don't let me stand in
> the way, since I've been explicit about being in favor of collaboration.
>
> W3C and Ecma both have transparency issues, but I don't expect those to be
> fixed easily. I mentioned them ("People in dark-glass houses ... [should not
> throw stones]") in reply to Maciej asserting greater openness on one side.
> Again this is not a "barrier" I'm trying to take down right now.
>
> /be
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Web IDL Garden Hose (was: ECMA TC 39 / W3C HTML and WebApps WG coordination)

[Yehuda Katz]

Something worth keeping in mind when thinking about low-traffic lists
is the context-switch cost for casual contributors. Even
very-low-traffic lists carry a very large historical and conceptual
overhead that must be loaded into one's brain when responding.

-- Yehuda


On Thu, Sep 24, 2009 at 3:19 PM, Brendan Eich  wrote:
> On Sep 24, 2009, at 2:43 PM, Doug Schepers wrote:
>
> [much appreciated information snipped -- thanks!]
>
>> I really don't see how the review process and accountability could be much
>> more open for the development of Web IDL elsewhere, nor is the burden on
>> reviewers that large... it would simply be one more low-traffic mailing
>> list.  Are there other barriers you see?
>
> I alluded to employers who are not currently paying W3C members not wanting
> their employees participating, even individually. I'll let one notable
> example that I know of speak for himself.
>
> The "mailing list as firehose" problem can be solved with enough work, but
> with two standards groups there is always greater risk of conflict, and just
> competition for attention. Two lists is simply one more list than one list
> to keep up with.
>
> This is a price of collaboration at wider scale, so don't let me stand in
> the way, since I've been explicit about being in favor of collaboration.
>
> W3C and Ecma both have transparency issues, but I don't expect those to be
> fixed easily. I mentioned them ("People in dark-glass houses ... [should not
> throw stones]") in reply to Maciej asserting greater openness on one side.
> Again this is not a "barrier" I'm trying to take down right now.
>
> /be
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

WebIDL

[Yehuda Katz]

long length;
  readonly attribute WindowProxy top;
  [Replaceable] readonly attribute WindowProxy opener;
  readonly attribute WindowProxy parent;
  readonly attribute Element frameElement;
  WindowProxy open(in optional DOMString url, in optional DOMString
target, in optional DOMString features, in optional DOMString
replace);
  getter WindowProxy (in unsigned long index);
  getter WindowProxy (in DOMString name);

  // the user agent
  readonly attribute Navigator navigator;
  readonly attribute ApplicationCache applicationCache;

  // user prompts
  void alert(in DOMString message);
  boolean confirm(in DOMString message);
  DOMString prompt(in DOMString message, in optional DOMString default);
  void print();
  any showModalDialog(in DOMString url, in optional any argument);

  // cross-document messaging
  void postMessage(in any message, in DOMString targetOrigin);
  void postMessage(in any message, in MessagePortArray ports, in
DOMString targetOrigin);

  // event handler IDL attributes
   attribute Function onabort;
   attribute Function onafterprint;
   attribute Function onbeforeprint;
   attribute Function onbeforeunload;
   attribute Function onblur;
   attribute Function oncanplay;
   attribute Function oncanplaythrough;
   attribute Function onchange;
   attribute Function onclick;
   attribute Function oncontextmenu;
   attribute Function ondblclick;
   attribute Function ondrag;
   attribute Function ondragend;
   attribute Function ondragenter;
   attribute Function ondragleave;
   attribute Function ondragover;
   attribute Function ondragstart;
   attribute Function ondrop;
   attribute Function ondurationchange;
   attribute Function onemptied;
   attribute Function onended;
   attribute Function onerror;
   attribute Function onfocus;
   attribute Function onformchange;
   attribute Function onforminput;
   attribute Function onhashchange;
   attribute Function oninput;
   attribute Function oninvalid;
   attribute Function onkeydown;
   attribute Function onkeypress;
   attribute Function onkeyup;
   attribute Function onload;
   attribute Function onloadeddata;
   attribute Function onloadedmetadata;
   attribute Function onloadstart;
   attribute Function onmessage;
   attribute Function onmousedown;
   attribute Function onmousemove;
   attribute Function onmouseout;
   attribute Function onmouseover;
   attribute Function onmouseup;
   attribute Function onmousewheel;
   attribute Function onoffline;
   attribute Function ononline;
   attribute Function onpause;
   attribute Function onplay;
   attribute Function onplaying;
   attribute Function onpopstate;
   attribute Function onprogress;
   attribute Function onratechange;
   attribute Function onreadystatechange;
   attribute Function onredo;
   attribute Function onresize;
   attribute Function onscroll;
   attribute Function onseeked;
   attribute Function onseeking;
   attribute Function onselect;
   attribute Function onshow;
   attribute Function onstalled;
   attribute Function onstorage;
   attribute Function onsubmit;
   attribute Function onsuspend;
   attribute Function ontimeupdate;
   attribute Function onundo;
   attribute Function onunload;
   attribute Function onvolumechange;
   attribute Function onwaiting;
};
Window implements EventTarget;


--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: arguments.callee in Harmony

[Yehuda Katz]

Thanks for the pointer. It seems like the argument against it is security:
if I pass you my arguments object, you now have access to the original
function, which violates the POLA.
Isn't the fact (pointed out by Allen in the original thread) that
arguments.callee can be deleted a mitigating factor here?

Aren't there other fixes that would work as well (such as making
arguments.callee only available lexically) without completely removing the
feature.

On a related topic, would you mind pointing me at the thread where the
removal of with() was discussed?

-- Yehuda

On Thu, Sep 24, 2009 at 5:51 PM, Breton Slivka  wrote:

> On Fri, Sep 25, 2009 at 10:49 AM, Breton Slivka  wrote:
> > x
> >
> >
> > On Fri, Sep 25, 2009 at 9:31 AM, Yehuda Katz  wrote:
> >> What I'd like to know is what the rationale for removing
> arguments.callee
> >> from strict mode is. Is it a performance problem? If so, have
> implementors
> >> tried other solutions at compile-time before agitating for the removal
> of a
> >> language feature?
> >> The argument that this is simply a strict mode change falls flat when
> we're
> >> also told that Harmony will be built on ES5 strict mode. As far as I'm
> >> concerned, anything missing in strict mode is effectively being removed
> from
> >> the language.
> >> -- Yehuda
> >
> > https://mail.mozilla.org/pipermail/es-discuss/2009-March/008970.html
> >
>
>
> Apologies with the curt message. I seem to have suddenly lost my
> ability to operate my computer competantly.
>
> I meant to say, that the rational has been discussed at length in the
> past. Here's the link to the mailing list thread about it:
>
> https://mail.mozilla.org/pipermail/es-discuss/2009-March/008970.html
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: arguments.callee in Harmony

[Yehuda Katz]

My general concern about strict mode is that it seems to be the result of a
smoke-filled-room compromise. I'd like to see the perspective of JavaScript
practitioners consulted about the strict mode definition (especially if it's
going to form the basis for ES Harmony).
-- Yehuda

On Thu, Sep 24, 2009 at 5:04 PM, Breton Slivka  wrote:

> On Fri, Sep 25, 2009 at 9:26 AM, Brendan Eich  wrote:
> > On Sep 24, 2009, at 4:06 PM, Charles Jolley wrote:
> >
> >> I'm curious, why not just give anonymous functions a default name like
> >> "callee".  Or perhaps have "callee" defined in a function scope to
> represent
> >> the function?  That seems to be exactly the same as the above; it just
> makes
> >> it easier for developers.  Is there a perf issue here?
> >
> > No, there's simply a backward compatibility problem. Anonymous functions
> do
> > not inject any such name on the scope chain (in any object, new or
> expected,
> > on the scope chain). Changing the language to inject callee (even in an
> ES5
> > declarative envirnment frame) is not backward compatible and probably
> will
> > break some content out there that uses callee in an outer scope to mean
> > something else.
> >
> > /be
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
> this discussion reminds me a little bit of the aspect oriented pattern
> that has been used in javascript on occasion. The idea there is that
> it's possible to replace a function with a wrapped version of the
> function that has the original function in the outer scope.
>
> So for instance:
>
> var myarray = [3,4,5];
> myarray.toString = (function () {
>   var ofunc = myarray.toString;
>   return function () {
>return "Extended toString: "+ofunc.apply(this,arguments);
>   }
> })()
>
> myarray.toString(); //returns "Extended toString: 3,4,5"
>
> This pattern can be generalised:
>
> function extendFunc (object, methodname, func) {
>var ofunc = object[methodname];
>object[methodname]=function () {
>return func.apply(object,[ofunc].concat(arguments));
>}
>
> }
>
> you can see that in that version, the new function recieves the old
> function as its first parameter.
>
> Now, my specific implementation has almost certainly got some flaws in
> it (not a lot of error checking or robustness), I'm sure- and people
> will argue about the details. It's the basic idea of aspect
> orientation that I'm trying to get at here.
>
> The reason I'm bringing this up though is that this is a simple highly
> general building block that can be used to build the super
> abstraction, I believe (among many other useful abstractions). It's
> also implementable in current ecmascript, and it's something that
> could become canonized as a native function in a future version of
> ecmascript- similar to the array extras that were first in the
> prototype library, but are now in ecmascript 5.
>
> There might be even more clever ways to build it so that it doesn't
> require an extra parameter (using "with" perhaps?) that could be used
> now, but built in native code and optimised in future editions.
> Anyway, I just thought I would put that out there for discussion.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

[Yehuda Katz]

That sounds reasonable. There are really two issues. One is that there are
parts of WebIDL that are unused. Another is that the parts of the spec
themselves are fairly arcane and very implementor-specific. Consider:
interface UndoManager {
  readonly attribute unsigned long length;
  getter any item(in unsigned long index);
  readonly attribute unsigned long position;
  unsigned long add(in any data, in DOMString title);
  void remove(in unsigned long index);
  void clearUndo();
  void clearRedo();
};

I almost forget that I'm looking at something most widely implemented in a
dynamic language when I look at that. Since this is most likely to be
implemented in terms of ECMAScript, why not provide an ECMAScript reference
implementation?

-- Yehuda

On Thu, Sep 24, 2009 at 1:49 PM, Maciej Stachowiak  wrote:

>
> On Sep 24, 2009, at 12:00 PM, Yehuda Katz wrote:
>
> I'll think about it. I was mostly hoping to start a discussion about
> alternatives. I think the bottom line here is that while the spec is
> well-optimized for implementors, it is not very well optimized for
> consumers. I suppose it would be possible to say that this stuff is *only*
> for implementors. I'd prefer if it were also readable for those trying to
> use the specification.
>
>
> My inclination would be to address this by improving the current Web IDL
> spec,  or to write an informative "primer" style document to accompany it. I
> also think some of the complexity of the Web IDL spec can probably be
> removed without losing anything important - I think it offers some
> constructs that are not used by any spec relying on it.
>
>  - Maciej
>
>
> -- Yehuda
>
> On Thu, Sep 24, 2009 at 11:17 AM, Maciej Stachowiak  wrote:
>
>>
>> On Sep 24, 2009, at 11:11 AM, Yehuda Katz wrote:
>>
>> Is it really true that WebIDL and the vague way DOM2 was described are the
>> only two options? Surely that's a false dilemma?
>>
>>
>> I'm not saying those are the only two options. I'm explaining how WebIDL
>> solves a problem. Are there other ways to solve the problem? Probably. Do
>> you have a specific proposal?
>>
>> Regards,
>> Maciej
>>
>>
>> -- Yehuda
>>
>> On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak wrote:
>>
>>>
>>> On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:
>>>
>>> Maybe this would be a good opportunity to revisit the utility of WebIDL
>>> in specifications (as formal specifications were re-examined for
>>> ES-Harmony). The WebIDL spec is pretty large, and I personally have found
>>> its use a confounding factor in understanding other specs (like HTML5).
>>>
>>>
>>> Its utility is in providing a way to specify API behavior in a way that
>>> is consistent between specifications, language-independent, and reasonably
>>> concise. It's true that it adds an additional thing you have to learn.
>>> That's regrettable, but there are a lot of details that need to be specified
>>> to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many
>>> details undefined, leading to problematic behavior differences among
>>> browsers and a need for mutual reverse-engineering.
>>>
>>> Regards,
>>> Maciej
>>>
>>> [1] http://www.w3.org/TR/DOM-Level-2-Core/
>>>
>>>
>>>
>>> -- Yehuda
>>>
>>> On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich wrote:
>>>
>>>> On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote:
>>>>
>>>>  It seems like this is a Web IDL issue. I don't see any reason for Web
>>>>> IDL to move to ECMA. It is a nominally language-independent formalism 
>>>>> that's
>>>>> being picked up by many W3C specs, and which happens to have ECMAScript as
>>>>> one of the target languages. Much of it is defined by Web compatibility
>>>>> constraints which would be outside the core expertise of TC39.
>>>>>
>>>>
>>>> Some of us on TC39 have lots of Web compatibility experience :-P.
>>>>
>>>>
>>>>  Probably the best thing to do is to provide detailed technical review
>>>>> of Web IDL via the W3C process.
>>>>>
>>>>
>>>> Expertise on both sides of the artificial standards body divide may very
>>>> well be needed. The rest of this message convinces me it is needed.
>>>>
>>>> One problem with inviting review via the W3C process is getting
>>>> attention and following too many fireh

Re: arguments.callee in Harmony

[Yehuda Katz]

What I'd like to know is what the rationale for removing arguments.callee
from strict mode is. Is it a performance problem? If so, have implementors
tried other solutions at compile-time before agitating for the removal of a
language feature?
The argument that this is simply a strict mode change falls flat when we're
also told that Harmony will be built on ES5 strict mode. As far as I'm
concerned, anything missing in strict mode is effectively being removed from
the language.

-- Yehuda

On Thu, Sep 24, 2009 at 4:26 PM, Brendan Eich  wrote:

> On Sep 24, 2009, at 4:06 PM, Charles Jolley wrote:
>
>  I'm curious, why not just give anonymous functions a default name like
>> "callee".  Or perhaps have "callee" defined in a function scope to represent
>> the function?  That seems to be exactly the same as the above; it just makes
>> it easier for developers.  Is there a perf issue here?
>>
>
> No, there's simply a backward compatibility problem. Anonymous functions do
> not inject any such name on the scope chain (in any object, new or expected,
> on the scope chain). Changing the language to inject callee (even in an ES5
> declarative envirnment frame) is not backward compatible and probably will
> break some content out there that uses callee in an outer scope to mean
> something else.
>
> /be
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

[Yehuda Katz]

I'll think about it. I was mostly hoping to start a discussion about
alternatives. I think the bottom line here is that while the spec is
well-optimized for implementors, it is not very well optimized for
consumers. I suppose it would be possible to say that this stuff is *only*
for implementors. I'd prefer if it were also readable for those trying to
use the specification.
-- Yehuda

On Thu, Sep 24, 2009 at 11:17 AM, Maciej Stachowiak  wrote:

>
> On Sep 24, 2009, at 11:11 AM, Yehuda Katz wrote:
>
> Is it really true that WebIDL and the vague way DOM2 was described are the
> only two options? Surely that's a false dilemma?
>
>
> I'm not saying those are the only two options. I'm explaining how WebIDL
> solves a problem. Are there other ways to solve the problem? Probably. Do
> you have a specific proposal?
>
> Regards,
> Maciej
>
>
> -- Yehuda
>
> On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak  wrote:
>
>>
>> On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:
>>
>> Maybe this would be a good opportunity to revisit the utility of WebIDL in
>> specifications (as formal specifications were re-examined for ES-Harmony).
>> The WebIDL spec is pretty large, and I personally have found its use a
>> confounding factor in understanding other specs (like HTML5).
>>
>>
>> Its utility is in providing a way to specify API behavior in a way that is
>> consistent between specifications, language-independent, and reasonably
>> concise. It's true that it adds an additional thing you have to learn.
>> That's regrettable, but there are a lot of details that need to be specified
>> to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many
>> details undefined, leading to problematic behavior differences among
>> browsers and a need for mutual reverse-engineering.
>>
>> Regards,
>> Maciej
>>
>> [1] http://www.w3.org/TR/DOM-Level-2-Core/
>>
>>
>>
>> -- Yehuda
>>
>> On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich wrote:
>>
>>> On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote:
>>>
>>>  It seems like this is a Web IDL issue. I don't see any reason for Web
>>>> IDL to move to ECMA. It is a nominally language-independent formalism 
>>>> that's
>>>> being picked up by many W3C specs, and which happens to have ECMAScript as
>>>> one of the target languages. Much of it is defined by Web compatibility
>>>> constraints which would be outside the core expertise of TC39.
>>>>
>>>
>>> Some of us on TC39 have lots of Web compatibility experience :-P.
>>>
>>>
>>>  Probably the best thing to do is to provide detailed technical review of
>>>> Web IDL via the W3C process.
>>>>
>>>
>>> Expertise on both sides of the artificial standards body divide may very
>>> well be needed. The rest of this message convinces me it is needed.
>>>
>>> One problem with inviting review via the W3C process is getting attention
>>> and following too many firehose-like mailing lists.
>>> es-discuss@mozilla.org is at most a garden hose, which is an advantage.
>>>
>>> Another problem is that not all Ecma TC39 members are W3C members (their
>>> employers are not members, that is).
>>>
>>> There are transparency problems on both sides, IMHO. People in dark-glass
>>> houses...
>>>
>>>
>>>
>>>>> https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
>>>>> and the rest of that thread
>>>>>
>>>>>
>>>>> https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
>>>>> (not the transactional behavior, which is out -- just the
>>>>> interaction with Array's custom [[Put]]).
>>>>>
>>>>> https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
>>>>>  on an "ArrayLike interface" with references to DOM docs at the bottom
>>>>>
>>>>> https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
>>>>>  about a WebIDL float terminal value issue.
>>>>>
>>>>
>>>> It seems like these are largely Web IDL issues (to the extent I can
>>>> identify issues in the threads at all).
>>>>
>>>
>>> TC39 members, Mark Miller articulated this yesterday, hope to restrict
>>> host objects in future versions of the JavaScript standard from doing any
>>> nut

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

[Yehuda Katz]

Is it really true that WebIDL and the vague way DOM2 was described are the
only two options? Surely that's a false dilemma?
-- Yehuda

On Thu, Sep 24, 2009 at 10:53 AM, Maciej Stachowiak  wrote:

>
> On Sep 24, 2009, at 10:36 AM, Yehuda Katz wrote:
>
> Maybe this would be a good opportunity to revisit the utility of WebIDL in
> specifications (as formal specifications were re-examined for ES-Harmony).
> The WebIDL spec is pretty large, and I personally have found its use a
> confounding factor in understanding other specs (like HTML5).
>
>
> Its utility is in providing a way to specify API behavior in a way that is
> consistent between specifications, language-independent, and reasonably
> concise. It's true that it adds an additional thing you have to learn.
> That's regrettable, but there are a lot of details that need to be specified
> to get interoperability. Pre-WebIDL specs such as DOM Level 2[1] left many
> details undefined, leading to problematic behavior differences among
> browsers and a need for mutual reverse-engineering.
>
> Regards,
> Maciej
>
> [1] http://www.w3.org/TR/DOM-Level-2-Core/
>
>
>
> -- Yehuda
>
> On Thu, Sep 24, 2009 at 9:47 AM, Brendan Eich  wrote:
>
>> On Sep 24, 2009, at 7:55 AM, Maciej Stachowiak wrote:
>>
>>  It seems like this is a Web IDL issue. I don't see any reason for Web IDL
>>> to move to ECMA. It is a nominally language-independent formalism that's
>>> being picked up by many W3C specs, and which happens to have ECMAScript as
>>> one of the target languages. Much of it is defined by Web compatibility
>>> constraints which would be outside the core expertise of TC39.
>>>
>>
>> Some of us on TC39 have lots of Web compatibility experience :-P.
>>
>>
>>  Probably the best thing to do is to provide detailed technical review of
>>> Web IDL via the W3C process.
>>>
>>
>> Expertise on both sides of the artificial standards body divide may very
>> well be needed. The rest of this message convinces me it is needed.
>>
>> One problem with inviting review via the W3C process is getting attention
>> and following too many firehose-like mailing lists.
>> es-discuss@mozilla.org is at most a garden hose, which is an advantage.
>>
>> Another problem is that not all Ecma TC39 members are W3C members (their
>> employers are not members, that is).
>>
>> There are transparency problems on both sides, IMHO. People in dark-glass
>> houses...
>>
>>
>>
>>>> https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003312.html
>>>> and the rest of that thread
>>>>
>>>>
>>>> https://mail.mozilla.org/pipermail/es5-discuss/2009-September/003343.html
>>>> (not the transactional behavior, which is out -- just the
>>>> interaction with Array's custom [[Put]]).
>>>>
>>>> https://mail.mozilla.org/pipermail/es-discuss/2009-May/009300.html
>>>>  on an "ArrayLike interface" with references to DOM docs at the bottom
>>>>
>>>> https://mail.mozilla.org/pipermail/es5-discuss/2009-June/002865.html
>>>>  about a WebIDL float terminal value issue.
>>>>
>>>
>>> It seems like these are largely Web IDL issues (to the extent I can
>>> identify issues in the threads at all).
>>>
>>
>> TC39 members, Mark Miller articulated this yesterday, hope to restrict
>> host objects in future versions of the JavaScript standard from doing any
>> nutty thing they like, possibly by collaborating with WebIDL standardizers
>> so that instead of "anything goes" for host objects, we have "only what
>> WebIDL can express".
>>
>> Catch-all magic where host object interfaces handle arbitrary property
>> gets and puts are currently not implementable in ES -- this may be possible
>> in a future edition, but even then it will carry performance penalties and
>> introduce analysis hazards. We hope to steer ES bindings for
>> WebIDL-expressed interfaces away from catch-all patterns.
>>
>> Beyond this tarpit, we're interested in the best way to linearize
>> multiply-inherited WebIDL interfaces onto prototype chains, or whether to
>> use prototype chains at all -- or in the seemingly unlikely event ES grows
>> first-class method-suite mixins, binding WebIDL inheritance to those. We
>> would welcome use-cases and collobaration, at least I would. Who knows what
>> better system might result?
>>
>>
>>  There are larger (and less precise concerns at this 

Re: ECMA TC 39 / W3C HTML and WebApps WG coordination

[Yehuda Katz]

re - seems
>> hard to discuss fruitfully without more detail.
>>
>
> The term I used was "execution model". "scope" is a mis-transcription.
>
>
>  We should take steps to address the following "willful violation":
>>>
>>> If the script's global object is a Window object, then in JavaScript,
>>> the this keyword in the global scope must return the Window object's
>>> WindowProxy object.
>>>
>>> This is a willful violation of the JavaScript specification current at
>>> the time of writing (ECMAScript edition 3). The JavaScript
>>> specification requires that the this keyword in the global scope
>>> return the global object, but this is not compatible with the security
>>> design prevalent in implementations as specified herein. [ECMA262]
>>>
>>
>> Wasn't ES5 fixed to address this?
>>
>
> No, nothing was changed in ES5 and it is not clear without more discussion
> with various experts active in whatwg, w3, and Ecma what to do.
>
> Since you asked, I think you make the case that we should collaborate a bit
> more closely.
>
>
>  I know the feedback was passed along.
>>
>
> Yes, but describing the problem does not give the solution.
>
> /be
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Strengthening Function.prototype.toString

[Yehuda Katz]

I use toString in a test suite that I built (jspec) to simplify the testing
DSL. Effectively, I extract the string contents of the function, and build a
new function with parameters representing some methods I want to make
available inside, and then call the function with those methods as
parameters.
It's a little bit of a hack, but protects the global namespace and allows me
to keep the DSL simple.

I believe Screw.Unit uses the same technique, as it's based on my original
jspec proof-of-concept.

Also, if toString() was guaranteed to return a valid JS representation of
the original function, it would be theoretically possible to mutate
functions (a la lisp macros) with a pure-JS JS parser. For the most part, I
have assumed that a correct toString() is available on implementations I'm
worried about people wanting to run jspec.

-- Yehuda

2008/9/26 Juriy Zaytsev <[EMAIL PROTECTED]>

>
> On Sep 26, 2008, at 5:32 PM, Hallvord R. M. Steen wrote:
>
> On Fri, 26 Sep 2008 19:58:27 +0200, liorean <[EMAIL PROTECTED]> wrote:
>
> 2008/9/26 Erik Arvidsson <[EMAIL PROTECTED]>:
>
> I know that Opera on mobile phones used to return a string
>
> representation that did not reflect the original.
>
>
> Yeah. Opera Mobile returned "[ECMAScript code]" or "[ecmascript
>
> code]". This was contrary to the ES3 spec (must be parsable as a
>
> function definition, IIRC) and also breaks the eval roundtripping by
>
> throwing a parse error.
>
> Anybody know if those issues have been fixed in more modern versions?
>
>
> No, not consistently across "modern versions". It's not likely to be
> properly "fixed" for a while yet. The reason is that on many platforms
> where memory is scarce, not enabling JS decompilation helps reduce memory
> requirements.
>
> Unfortunately several major libraries (prototype in particular, jQuery to
> a minor extent) have started (ab)using decompilation for various purposes.
>
> Pages that rely on this tend to malfunction in Opera on low-memory
> devices. Some Opera versions make at least some of these pages work again
> by returning "function(){[ecmascript code]}" instead but that's of course
> a silly hack..
>
> (It would be great if ES-next could have a look at why these libraries
> rely on toString - hacks and make it possible to do equivalent things with
>
> nicer language constructs. One of the reasons toString is used is probably
>
> outside the group's scope and caused by typeOf bugs in IE: prototype's
> isFunction method uses toString in order to reliably detect whether
> something is a function reference. Another usage is apparently - from my
>
>
> That's what jQuery's `isFunction` used to do. Afaik, they reverted it to a
> simple `instanceof` check just recently. In prototype.js, on the other hand,
> we tried to work around cross-frame "issues" that arise when using
> `instanceof`. Doing a `typeof` check (of both an object and its call
> property) seems to be sufficient.
>
>
> memory - to look at the names of the named arguments and do something
> magic if the first argument is $super. I'm not up-to-date on whether the
> next iteration has an elegant solution for this apparent requirement.)
>
>
> Latest build does the same thing. That "something magic" is actually just
> creating a reference to a "super" method (same-named method of a parent
> class). Function decompilation, while non-standard, seems to be the best
> solution when implementing such inheritance mechanism. We would gladly
> consider alternative (more compliant) solutions, if any exist.
>
>
>
> --
> Hallvord R. M. Steen
> Core QA JavaScript tester, Opera Software
> http://www.opera.com/
> Opera - simply the best Internet experience
> ___
> Es-discuss mailing list
> Es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> --
> *Juriy Zaytsev*
> *
> *
>
> ___
> Es-discuss mailing list
> Es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

noSuchMethod?

[Yehuda Katz]

Has any thought been given to adding Object#__noSuchMethod__ or the like
(propertyNotFound, method_missing, or whatever it would be called) in
ES3.1/Harmony?

I ask because another commonly requested feature, mixins, is easily
implementable in terms of noSuchMethod and getters/setters.

I'm not sure about the implications for implementors or performance
(noSuchMethod probably requires a second method lookup pass; I'm not sure
how much overhead method lookup has in JS), but being able to override
method dispatch itself via a mechanism like this is very powerful.

-- 
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss