Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

[Tom Van Cutsem]

Allen and I had a conversation that clarified things.

Essentially, the plan is to only have
[[PreventExtensions]]/[[IsExtensible]] internal MOP methods, and to only
have the corresponding preventExtensions/isExtensible traps for proxies.

Proxies won't have isSealed, isFrozen, seal and frozen traps and there will
be no corresponding Reflect.{isSealed,isFrozen,seal,frozen} methods.

Calling Object.freeze(proxy) instead triggers the proxy's
getOwnPropertyNames trap and then updates each own property of the proxy
via defineProperty. Similar story for Object.isFrozen(proxy).

Pro:
- We get rid of 4 MOP methods
([[Freeze]],[[Seal]],[[IsFrozen]],[[IsSealed]]). This simplifies both the
internal MOP and the Proxy API.
- Freezing and sealing always behave consistently, even in the face of
proxies. There's no chance for a proxy to implement multiple traps
inconsistently.

Con:
- Object.freeze(proxy) and Object.isFrozen(proxy) must observably iterate
over all own properties of the proxy (same for seal/isSealed).

Cheers,
Tom

2013/3/18 Tom Van Cutsem 

> Ok, somehow I had completely missed "9.3.10 TestIntegrityLevel (O, level)"
> which does exactly the derived computation for sealed and frozen objects.
>
> I think André is right though about the bug in 8.3.3 step 2.a.
>
> Cheers,
> Tom
>
>
> 2013/3/17 Allen Wirfs-Brock 
>
>> Tom recently suggested that that we really don't need MOP-level or trap
>> operations from freezing, sealing and testing those states.  Also, there
>> seems to be minimal support for having explicit freeze/sealed integrity
>> states or for adding integrity integrity states.  So I'm probably going to
>> go make to an style design.  We'll only have [[IsExtensible]] and
>> [[PreventExtensions]] MOP/trap/Reflect operations.
>>  Object.freeze/seal/isFrozen/isSealed will be derived operations.
>>
>> Allen
>>
>>
>>
>> On Mar 17, 2013, at 10:16 AM, Tom Van Cutsem wrote:
>>
>> Hi,
>>
>> Allen's latest draft (Rev. 14) contains the change where
>> [[Freeze]],[[Seal]] and [[PreventExtensions]] have been consolidated into
>> [[HasIntegrity]]/[[SetIntegrity]]. While no changes were made to the Proxy
>> API (i.e. no has/getIntegrity traps yet), the definition of
>> Object.{freeze,seal,preventExtensions} did change, and this is sufficient
>> to expose an incompatibility with ES5, namely:
>>
>> Object.isFrozen(Object.preventExtensions({})) // true in ES5, false in
>> ES6 Rev14 draft
>>
>> I still feel like the consolidation isn't worth this incompatibility.
>>
>>  Allen, could you clarify what your intent is? Is it your intent that
>> this incompatibility will be fixed with further spec changes?
>>
>> Cheers,
>> Tom
>>
>> 2013/2/21 Brendan Eich 
>>
>>> Tom Van Cutsem wrote:
>>>
 That said, I don't think this is enough evidence either for or against
 the breaking change.

>>>
>>> I have a hard time believing we can break ES5. It has been shipping for
>>> years (plural, at least in one case) in major browsers that evergreen their
>>> user bases.
>>>
>>> /be
>>>
>>
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Where is it specified that new objects are empty, if it is?

[Andreas Rossberg]

On 18 March 2013 18:18, Brendan Eich  wrote:
> Andreas Rossberg wrote:
>>
>> On 18 March 2013 17:43, Brendan Eich  wrote:
>>>
>>> Andreas Rossberg wrote:

 In the process of adopting the new __proto__ semantics, we have
 recently changed it to be a magic data property on Object.prototype.
 In a next step, we will make it a proper JS accessor property.
>>>
>>> Are you poisoning reflection, or returning poison-pill getter and setter?
>>
>> Currently neither
>
> Right, I meant when you make it an accessor.

We plan to follow what the draft spec will say once it's there ;).
IIRC we agreed on poison pill last time round.

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

Re: Four static scoping violations in ES5 sloppy

[Sam Tobin-Hochstadt]

On Mon, Mar 18, 2013 at 1:17 PM, Brendan Eich  wrote:
> With a custom loader, sure. Possibly this can be made into a one-liner.

The constructor for new loaders takes a global as an argument.  So
yes, this is a one-liner.

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

Re: March 14, 2013 TC39 Meeting Notes

[Brendan Eich]

Kevin Smith wrote:
FWIW, in my estimation, tagless template strings which interpolate by 
default are one of the top 5 usability improvements in ES6.


Agreed.

Dave's point, that the use-cases for tagless template strings outnumber 
innerHTML XSS-concern use-cases by a large factor, is important.


Doug Crockford observed that template strings won over String.format in 
large part because of greater opportunity for safer APIs. But this cut 
both ways, since removing tagless template strings will not necessarily 
make everone use


str`a ${b} c`

where they could have used

`a ${b} c`

with an appropriate str binding. And adding such a str binding will, by 
the safety-first argument, lead people away from


html`a ${b} c`

Making the str name longer and harder to use will simply leave people 
inventing String.format libraries.


As always, unusable but safer APIs should be viewed as unsafe because 
not usable, so not used.


The committee did not reach an agreement, but we will keep working to 
serve the most common use-cases. I think this must mean tagless template 
strings that interpolate, as proposed and accepted for ES6.


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

Re: Where is it specified that new objects are empty, if it is?

[Brendan Eich]

Andreas Rossberg wrote:

On 18 March 2013 17:43, Brendan Eich  wrote:

Andreas Rossberg wrote:

In the process of adopting the new __proto__ semantics, we have
recently changed it to be a magic data property on Object.prototype.
In a next step, we will make it a proper JS accessor property.

Are you poisoning reflection, or returning poison-pill getter and setter?


Currently neither


Right, I meant when you make it an accessor.

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

Re: Four static scoping violations in ES5 sloppy

[Brendan Eich]

Andreas Rossberg wrote:

On 18 March 2013 17:48, Brendan Eich  wrote:

Andreas Rossberg wrote:

Maybe I misunderstand what you mean, but unfortunately, the global
object will remain at the top of the scope chain in ES6, even with
modules (though complemented with a lexical environment for new
binding forms). We shied away from fixing that mistake.

Don't break the web.

Versioning is an anti-pattern.

I don't think "shied away" is accurate. We couldn't fix that mistake.


I think we could have fixed it for modules. Whether that would have
been worth it I don't know.


For modules with the standard loader, it would be not web-breaking but 
pretty code-migration-hostile to remove the global.


With a custom loader, sure. Possibly this can be made into a one-liner.

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

Re: Four static scoping violations in ES5 sloppy

[Till Schneidereit]

Wasn't there some talk about an option to remove global from a
module's scope chain? Probably in the module loader? I seem to
remember that being discussed. I don't, however, remember ever seeing
a decision for or against such a solution.

On Mon, Mar 18, 2013 at 6:04 PM, Mark S. Miller  wrote:
> Sadness. I had misremembered how all that finally resolved. In that moment,
> I thought we had decided to fix that for modules. But now that you mention
> it, I remember the discussion. These are difficult issues, and I was not
> trying to suggest we reopen them.
>
> In any case, regarding the new #1 and #3 restrictions in ES5 strict, the
> most we can say is that it cleared the ground in hopes of better scoping in
> ES6, but it didn't turn out that way. Oh well. Was worth a shot.
>
>
>
> On Mon, Mar 18, 2013 at 9:46 AM, Andreas Rossberg 
> wrote:
>>
>> On 18 March 2013 17:32, Mark S. Miller  wrote:
>> > And why does ES5/strict impose these restrictions, when they are not
>> > necessary for the formal criterion?
>> >
>> > Because ES5 strict mode, being an opt-in, gave us a rare opportunity to
>> > clean things up in preparation for yet better scoping in ES6. I'm
>> > pleased to
>> > report that it mostly turned out that way. Because of #1 and #3, ES5
>> > strict
>> > code will be easier to refactor into ES6 modules, where the global
>> > object is
>> > finally not on their scope chain. At the time we did this, we didn't
>> > anticipate this specific aspect of ES6, but took the opportunity to
>> > clear
>> > the ground.
>>
>> Maybe I misunderstand what you mean, but unfortunately, the global
>> object will remain at the top of the scope chain in ES6, even with
>> modules (though complemented with a lexical environment for new
>> binding forms). We shied away from fixing that mistake.
>>
>> /Andreas
>
>
>
>
> --
> 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: Four static scoping violations in ES5 sloppy

[Mark S. Miller]

Sadness. I had misremembered how all that finally resolved. In that moment,
I thought we had decided to fix that for modules. But now that you mention
it, I remember the discussion. These are difficult issues, and I was not
trying to suggest we reopen them.

In any case, regarding the new #1 and #3 restrictions in ES5 strict, the
most we can say is that it cleared the ground in hopes of better scoping in
ES6, but it didn't turn out that way. Oh well. Was worth a shot.



On Mon, Mar 18, 2013 at 9:46 AM, Andreas Rossberg wrote:

> On 18 March 2013 17:32, Mark S. Miller  wrote:
> > And why does ES5/strict impose these restrictions, when they are not
> > necessary for the formal criterion?
> >
> > Because ES5 strict mode, being an opt-in, gave us a rare opportunity to
> > clean things up in preparation for yet better scoping in ES6. I'm
> pleased to
> > report that it mostly turned out that way. Because of #1 and #3, ES5
> strict
> > code will be easier to refactor into ES6 modules, where the global
> object is
> > finally not on their scope chain. At the time we did this, we didn't
> > anticipate this specific aspect of ES6, but took the opportunity to clear
> > the ground.
>
> Maybe I misunderstand what you mean, but unfortunately, the global
> object will remain at the top of the scope chain in ES6, even with
> modules (though complemented with a lexical environment for new
> binding forms). We shied away from fixing that mistake.
>
> /Andreas
>



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

Re: Four static scoping violations in ES5 sloppy

[David Bruant]

Le 18/03/2013 17:48, Brendan Eich a écrit :

Andreas Rossberg wrote:

On 18 March 2013 17:32, Mark S. Miller  wrote:

And why does ES5/strict impose these restrictions, when they are not
necessary for the formal criterion?

Because ES5 strict mode, being an opt-in, gave us a rare opportunity to
clean things up in preparation for yet better scoping in ES6. I'm 
pleased to
report that it mostly turned out that way. Because of #1 and #3, ES5 
strict
code will be easier to refactor into ES6 modules, where the global 
object is

finally not on their scope chain. At the time we did this, we didn't
anticipate this specific aspect of ES6, but took the opportunity to 
clear

the ground.


Maybe I misunderstand what you mean, but unfortunately, the global
object will remain at the top of the scope chain in ES6, even with
modules (though complemented with a lexical environment for new
binding forms). We shied away from fixing that mistake.


Don't break the web.

Versioning is an anti-pattern.

I don't think "shied away" is accurate. We couldn't fix that mistake.
I don't understand the mention of "don't break the web". Modules aren't 
used on the web, so whatever rules are chosen for them they can't break 
the web.

I'm probably missing something here.

Maybe "global in the scope chain" has to be divided into 2 different 
meanings: "read" and "write" to the global scope.

My current understanding is as follow:
* code in a module body can read globals in the global scope
* code in a module cannot create a global properties (unless being hand 
off the global object specifically)
* the module name is part of the newly introduced lexical binding ("file 
local" global variables).


How far am I in understanding modules and scoping?

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

Re: March 14, 2013 TC39 Meeting Notes

[Kevin Smith]

FWIW, in my estimation, tagless template strings which interpolate by
default are one of the top 5 usability improvements in ES6.

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

Re: Four static scoping violations in ES5 sloppy

[Andreas Rossberg]

On 18 March 2013 17:48, Brendan Eich  wrote:
> Andreas Rossberg wrote:
>>
>> On 18 March 2013 17:32, Mark S. Miller  wrote:
>>>
>>> And why does ES5/strict impose these restrictions, when they are not
>>> necessary for the formal criterion?
>>>
>>> Because ES5 strict mode, being an opt-in, gave us a rare opportunity to
>>> clean things up in preparation for yet better scoping in ES6. I'm pleased
>>> to
>>> report that it mostly turned out that way. Because of #1 and #3, ES5
>>> strict
>>> code will be easier to refactor into ES6 modules, where the global object
>>> is
>>> finally not on their scope chain. At the time we did this, we didn't
>>> anticipate this specific aspect of ES6, but took the opportunity to clear
>>> the ground.
>>
>>
>> Maybe I misunderstand what you mean, but unfortunately, the global
>> object will remain at the top of the scope chain in ES6, even with
>> modules (though complemented with a lexical environment for new
>> binding forms). We shied away from fixing that mistake.
>
> Don't break the web.
>
> Versioning is an anti-pattern.
>
> I don't think "shied away" is accurate. We couldn't fix that mistake.

I think we could have fixed it for modules. Whether that would have
been worth it I don't know.

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

Re: Where is it specified that new objects are empty, if it is?

[Andreas Rossberg]

On 18 March 2013 17:43, Brendan Eich  wrote:
> Andreas Rossberg wrote:
>> In the process of adopting the new __proto__ semantics, we have
>> recently changed it to be a magic data property on Object.prototype.
>> In a next step, we will make it a proper JS accessor property.
>
> Are you poisoning reflection, or returning poison-pill getter and setter?

Currently neither -- because __proto__ is a magic data property, you
cannot extract any getter/setter. When you read the property
descriptor, though, its .value is null.

(Also, a funny side effect of the magic is that making that property
non-writable will prevent you from setting prototypes via __proto__.)

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

Re: Four static scoping violations in ES5 sloppy

[Brendan Eich]

Andreas Rossberg wrote:

On 18 March 2013 17:32, Mark S. Miller  wrote:

And why does ES5/strict impose these restrictions, when they are not
necessary for the formal criterion?

Because ES5 strict mode, being an opt-in, gave us a rare opportunity to
clean things up in preparation for yet better scoping in ES6. I'm pleased to
report that it mostly turned out that way. Because of #1 and #3, ES5 strict
code will be easier to refactor into ES6 modules, where the global object is
finally not on their scope chain. At the time we did this, we didn't
anticipate this specific aspect of ES6, but took the opportunity to clear
the ground.


Maybe I misunderstand what you mean, but unfortunately, the global
object will remain at the top of the scope chain in ES6, even with
modules (though complemented with a lexical environment for new
binding forms). We shied away from fixing that mistake.


Don't break the web.

Versioning is an anti-pattern.

I don't think "shied away" is accurate. We couldn't fix that mistake.

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

Re: Four static scoping violations in ES5 sloppy

[Andreas Rossberg]

On 18 March 2013 17:32, Mark S. Miller  wrote:
> And why does ES5/strict impose these restrictions, when they are not
> necessary for the formal criterion?
>
> Because ES5 strict mode, being an opt-in, gave us a rare opportunity to
> clean things up in preparation for yet better scoping in ES6. I'm pleased to
> report that it mostly turned out that way. Because of #1 and #3, ES5 strict
> code will be easier to refactor into ES6 modules, where the global object is
> finally not on their scope chain. At the time we did this, we didn't
> anticipate this specific aspect of ES6, but took the opportunity to clear
> the ground.

Maybe I misunderstand what you mean, but unfortunately, the global
object will remain at the top of the scope chain in ES6, even with
modules (though complemented with a lexical environment for new
binding forms). We shied away from fixing that mistake.

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

Re: Where is it specified that new objects are empty, if it is?

[Brendan Eich]

Andreas Rossberg wrote:

On 16 March 2013 00:00, Kevin Reid  wrote:

I'm doing a little maintenance on SES. Chrome has recently added a new
odd behavior:


var o = Object.create(null);
Object.getOwnPropertyNames(o)

[]

Object.getOwnPropertyDescriptor(o, '__proto__');

Object {value: null, writable: true, enumerable: false, configurable: false}


That seems to be the old odd behaviour, not the new. On V8 trunk you
get 'undefined' for the latter.

In the process of adopting the new __proto__ semantics, we have
recently changed it to be a magic data property on Object.prototype.
In a next step, we will make it a proper JS accessor property.


Are you poisoning reflection, or returning poison-pill getter and setter?

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

Re: Four static scoping violations in ES5 sloppy

[Mark S. Miller]

Interesting thread. After all this work trying to figure out what I meant,
I'm sorry to disappoint. Technically, Domenic is right: once we are rid of
"with" and non-strict "eval", #1 and #3 do not technically violate the
degree of static scoping provided by ES5.

So why are they on this list?

Because many who are not already intimately familiar with JS will be
properly outraged at #1 and #3 in non-strict mode, and appreciate that
strict mode cleans up scoping to the extent that it can.

And why does ES5/strict impose these restrictions, when they are not
necessary for the formal criterion?

Because ES5 strict mode, being an opt-in, gave us a rare opportunity to
clean things up in preparation for yet better scoping in ES6. I'm pleased
to report that it mostly turned out that way. Because of #1 and #3, ES5
strict code will be easier to refactor into ES6 modules, where the global
object is finally not on their scope chain. At the time we did this, we
didn't anticipate this specific aspect of ES6, but took the opportunity to
clear the ground.

And because implicit creation of global variables was incredibly hazardous,
turning misspellings into new global variables.



On Mon, Mar 18, 2013 at 6:30 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:

> From: Sam Tobin-Hochstadt
>
> > On Mon, Mar 18, 2013 at 8:40 AM, Andreas Rossberg 
> wrote:
> >>
> >> Nothing, but Sam probably meant to write:
> >>
> >> if (something_random()) xxx = 7;
> >> xxx; // ReferenceError or not?
> >
> > Right, I was confusing the problem this code describes, which is what I
> think Mark meant, with the problem of the global object being on the scope
> chain.
> >
> >>> It actually demonstrates how the situation is exactly the same with
> *explicit* global variable creation. Strict mode does nothing to change the
> result.
> >>>
> >>> Similarly, in case 3, the code could be `delete window.xxx` and we
> still cannot statically predict whether there's a `ReferenceError` on the
> subsequent line or not. Again, strict mode does not change the result.
> >>
> >> That is true, and the proper answer is that the global object should be
> on the above list as well. Not sure why Mark did not include it.
> >
> > I believe that Mark would distinguish 1-4, which are fixed by strict
> mode, from the global object, which is the remaining issue in ES5.
>
> Last time this came up:
>
> http://www.mail-archive.com/es-discuss@mozilla.org/msg18463.html
>
> it was clarified that the global object is not a static scoping violation,
> since it's the top-most in the scope chain. Thus we know that every binding
> that's not in the nested function environments must be on the global
> object—or not exist.
>
> That's the essence of my confusion. Cases 1 and 3 do not change things.
> That is, `xxx = 7` versus `window.xxx = 7` doesn't change where we
> determine `xxx` to be: it must be global (if it exists at all). Similarly,
> `delete xxx` versus `delete window.xxx` doesn't change that `xxx` must be
> global or not exist. And strict mode prohibits the former of these two
> forms, but doesn't prohibit the latter, and so seems to have no impact.
>
> Now, if `with` and sloppy `eval` weren't removed, I could see the
> argument, at least for `delete`:
>
> http://www.mail-archive.com/es-discuss@mozilla.org/msg18466.html
>
> but with those two gone (i.e. with 2 and 4 gone), 1 and 3 seem to not
> matter.
>
> > But only Mark can answer this for sure.
>
> Indeed :)
>



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

RE: Mutable Proto

[François REMY]

I certainly agree, but it has been decided otherwhise by the TC39 members and I 
doubt they’re willing to revert their decision.

 

 


De : Andrea Giammarchi
Envoyé : ‎18‎ ‎mars‎ ‎2013 ‎17‎:‎08
À : Nathan Wall
Cc : es-discuss@mozilla.org
Objet : Re: Mutable Proto



I would like to see Object.setPrototypeOf(object, proto) too and a disappeared 
__proto__ 'till now breaking too much.



It would be much easier to implement all shenanigans via 
Object.defineProperty(Object.prototype, '__proto__', {whatever}); rather than 
fix current non-standard __proto__ ... 




+1




On Mon, Mar 18, 2013 at 9:04 AM, Nathan Wall  wrote:

A previous thread [1] brought to my attention the fact that objects which don't 
inherit from Object.prototype won't have mutable __proto__.  This was something 
I had missed and breaks some scripts I'm currently using because I have objects 
which I don't want to inherit from Object.prototype but for which I do want to 
have mutable proto.

Testing in Firefox Nightly I found this workaround:

var x = { }, y = { foo: 'bar' };

x.__proto__ = y;
console.log(1, x.foo);
// => 1 'bar'

x.__proto__ = null;
console.log(2, x.foo);
// => 2 undefined

x.__proto__ = y;
console.log(3, x.foo);
// => 3 undefined

var _setPrototype = Object.getOwnPropertyDescriptor(Object.prototype, 
'__proto__').set,
setPrototypeOf = Function.prototype.call.bind(_setPrototype);
setPrototypeOf(x, y);
console.log(4, x.foo);
// => 4 'bar'

Is this workaround a temporary bug in Firefox's current implementation? Or will 
this be the spec'ed behavior for ES6? Can we use such a method to mutate 
prototype on objects which don't inherit from Object.prototype?


[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029176.html
___
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: Mutable Proto

[Andrea Giammarchi]

I would like to see Object.setPrototypeOf(object, proto) too and a
disappeared __proto__ 'till now breaking too much.

It would be much easier to implement all shenanigans via
Object.defineProperty(Object.prototype, '__proto__', {whatever}); rather
than fix current non-standard __proto__ ...

+1


On Mon, Mar 18, 2013 at 9:04 AM, Nathan Wall  wrote:

> A previous thread [1] brought to my attention the fact that objects which
> don't inherit from Object.prototype won't have mutable __proto__.  This was
> something I had missed and breaks some scripts I'm currently using because
> I have objects which I don't want to inherit from Object.prototype but for
> which I do want to have mutable proto.
>
> Testing in Firefox Nightly I found this workaround:
>
> var x = { }, y = { foo: 'bar' };
>
> x.__proto__ = y;
> console.log(1, x.foo);
> // => 1 'bar'
>
> x.__proto__ = null;
> console.log(2, x.foo);
> // => 2 undefined
>
> x.__proto__ = y;
> console.log(3, x.foo);
> // => 3 undefined
>
> var _setPrototype = Object.getOwnPropertyDescriptor(Object.prototype,
> '__proto__').set,
> setPrototypeOf = Function.prototype.call.bind(_setPrototype);
> setPrototypeOf(x, y);
> console.log(4, x.foo);
> // => 4 'bar'
>
> Is this workaround a temporary bug in Firefox's current implementation? Or
> will this be the spec'ed behavior for ES6? Can we use such a method to
> mutate prototype on objects which don't inherit from Object.prototype?
>
>
> [1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029176.html
> ___
> 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

Mutable Proto

[Nathan Wall]

A previous thread [1] brought to my attention the fact that objects which don't 
inherit from Object.prototype won't have mutable __proto__.  This was something 
I had missed and breaks some scripts I'm currently using because I have objects 
which I don't want to inherit from Object.prototype but for which I do want to 
have mutable proto.

Testing in Firefox Nightly I found this workaround:

    var x = { }, y = { foo: 'bar' };

    x.__proto__ = y;
    console.log(1, x.foo);
    // => 1 'bar'

    x.__proto__ = null;
    console.log(2, x.foo);
    // => 2 undefined

    x.__proto__ = y;
    console.log(3, x.foo);
    // => 3 undefined

    var _setPrototype = Object.getOwnPropertyDescriptor(Object.prototype, 
'__proto__').set,
        setPrototypeOf = Function.prototype.call.bind(_setPrototype);
    setPrototypeOf(x, y);
    console.log(4, x.foo);
    // => 4 'bar'

Is this workaround a temporary bug in Firefox's current implementation? Or will 
this be the spec'ed behavior for ES6? Can we use such a method to mutate 
prototype on objects which don't inherit from Object.prototype?


[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029176.html
  
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

March 13, 2013 TC39 Meeting Notes

[Rick Waldron]

# March 13 2013 Meeting Notes

John Neumann (JN), Norbert Lindenberg (NL), Allen Wirfs-Brock (AWB), Rick
Waldron (RW), Waldemar Horwat (WH), Eric Ferraiuolo (EF), Erik Arvidsson
(EA), Luke Hoban (LH), Matt Sweeney (MS), Doug Crockford (DC), Yehuda Katz
(YK), Brendan Eich (BE), Sam Tobin-Hochstadt (STH), Alex Russell (AR), Dave
Herman (DH), Adam Klein (AK), Bernd Mathiske (BM), John Pampuch (JP), Avik
Chaudhuri (AC), Edward O'Connor (EOC), Rick Hudson (RH), Andreas Rossberg
(ARB), Rafeal Weinstein (RWN), Mark Miller (MM), Reid Burke (RB), Edward
Yang (EY), Dan Stefan (DS),



## 4.14 Make new Date(dateObj)
(Presented by Allen Wirfs-Brock)

See: https://bugs.ecmascript.org/show_bug.cgi?id=1257

AWB: Propose to fix this by spec'ing the Date constructor to special case
date object arguments and produce an accurate copy of the date object.

DC: Produces a clone?

AWB: Yes.

DC: a Issues with toString?

AWB: No

NL: Bug mixes ES5/ES6 spec language: DefaultValue/DateValue?

AWB: Not an issue


**Conclusion/Resolution**

- When date object is passed to the Date constructor, it makes an accurate
copy of the date object.


## 4.4 Spec Update
(Presented by Allen Wirfs-Brock)

http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts

### RegExp global, ignoreCase, multiline, source, sticky are now prototype
accessor properties rather than instance own data properties.


AWB: WH's question, "why are the flags now accessor properties?" (re:
RegExp global, ignoreCase, multiline, source, sticky) is necessary to
support a web compatible "compile" method. The web reality takes an
existing instance and reinitializes a new instance.

MM: SES doesn't whitelist "compile", but could we specify "compile" to be
SES whitelistable. Freeze, no longer modifiable by compile

Example:

```js
var re = /abc/;

re.compile("changed");
console.log(re);
// > /changed/

Object.freeze(re);

re.compile("again");
console.log(re);
// > /again/

// oops
```

DC: What is the history of "compile"?

AWB: Not sure, but I believe it was JScript


### ArrayBuffer and TypedArray object length no longer restricted to 2^32
limit

DH: We should talk offline about making sure this is future proof

MM: is the new length 2^53? If it goes over, there will be a length that
can't be represented

...Mixed discussion about the length limitations of existing arrays.

AWB: Isn't really an issue, just allows the length of arrays to be
sufficiently large. I believe this is the future proof solution

ARB: Is it inconceivable that you might want to create a TypedArray backed
by a large mapped memory?

DH: Not inconceivable.
...Regardless of whether you want something 2^53 or above

YK: Agree with Allen that this is probably sufficient.

DH/AR: (brief discussion about ownership of TypedArray spec)



AWB: Can't use the same methods as Array, because they use 2^32 length.

MM: And are all generic, so really work on "array likes"

AWB: It's not clear that they _should_ work and it may not make sense to
have these methods. There are possible solutions

WH: An example of non backwards compatible?

MM: Sparse array that's not populated up to the limit and push on it? What
happens?

WH: Calls ToUint32 on it?

AWB: Yes

WH: Doesn't consider those array like?

AWB: Array spec, gets and sets, does its own Uint32
...Need to look at each of these methods and see what can be done to make
these compatible.

BE/AWB: (mixed discussion about historic compatibility issues)

BE: We can try it and the first sign of trouble, back off.

MM/AWB/BE: (agreement)

WH: The main use I see of ToUint32 is to call it on the existing length.
 Indices passed in as arguments are generally processed via ToInteger.  As
such, getting rid of the ToUint32 in generic Array methods applied to
non-Array objects shouldn't present much difficulty (when they're applied
to Array objects the change would be invisible because Array length can't
reach 2^32).

AWB: But it doesn't have to be an array
...We should move on.



## 4.5 Private Symbols, WeakMaps, and Relationships
(Presented by Mark Miller)

Slides (PDF, will prompt download):
http://wiki.ecmascript.org/lib/exe/fetch.php?id=meetings%3Ameeting_mar_12_2013&cache=cache&media=meetings:relationships.pdf

MM: Concerned about the overlap in functionality between WeakMaps and
private Symbols.

...WeakMap named with the word "Map" inverts the thinking.

...Allen noted that WeakMaps are about a Relationship, between two objects.

Legend:

**base** is **key**
**field** is **map**


(Slide 2)
___
**"Map" inverts thinking**
(the use of ">>" signifies the that the item on the LEFT is usually better
for most purposes then the RIGHT)

Syntax: base@field >> map.get(key)
...Describes the relationship more accurately

GC: impl(base)[field] >> impl(map)[key]
...A better implementation on the LEFT, despite most implementing the RIGHT

Lookup: Inherited props >> own props

Intuition: Relationship >> Symbol >> Map

Unique Symbols ok.
___

STH: Weak hash tables are found i

Re: get/setIntegrity trap (Was: A case for removing the seal/freeze/isSealed/isFrozen traps)

[Tom Van Cutsem]

Ok, somehow I had completely missed "9.3.10 TestIntegrityLevel (O, level)"
which does exactly the derived computation for sealed and frozen objects.

I think André is right though about the bug in 8.3.3 step 2.a.

Cheers,
Tom

2013/3/17 Allen Wirfs-Brock 

> Tom recently suggested that that we really don't need MOP-level or trap
> operations from freezing, sealing and testing those states.  Also, there
> seems to be minimal support for having explicit freeze/sealed integrity
> states or for adding integrity integrity states.  So I'm probably going to
> go make to an style design.  We'll only have [[IsExtensible]] and
> [[PreventExtensions]] MOP/trap/Reflect operations.
>  Object.freeze/seal/isFrozen/isSealed will be derived operations.
>
> Allen
>
>
>
> On Mar 17, 2013, at 10:16 AM, Tom Van Cutsem wrote:
>
> Hi,
>
> Allen's latest draft (Rev. 14) contains the change where
> [[Freeze]],[[Seal]] and [[PreventExtensions]] have been consolidated into
> [[HasIntegrity]]/[[SetIntegrity]]. While no changes were made to the Proxy
> API (i.e. no has/getIntegrity traps yet), the definition of
> Object.{freeze,seal,preventExtensions} did change, and this is sufficient
> to expose an incompatibility with ES5, namely:
>
> Object.isFrozen(Object.preventExtensions({})) // true in ES5, false in ES6
> Rev14 draft
>
> I still feel like the consolidation isn't worth this incompatibility.
>
>  Allen, could you clarify what your intent is? Is it your intent that
> this incompatibility will be fixed with further spec changes?
>
> Cheers,
> Tom
>
> 2013/2/21 Brendan Eich 
>
>> Tom Van Cutsem wrote:
>>
>>> That said, I don't think this is enough evidence either for or against
>>> the breaking change.
>>>
>>
>> I have a hard time believing we can break ES5. It has been shipping for
>> years (plural, at least in one case) in major browsers that evergreen their
>> user bases.
>>
>> /be
>>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Questions/issues regarding generators

[Andreas Rossberg]

On 16 March 2013 07:34, Allen Wirfs-Brock  wrote:
>
> On Mar 15, 2013, at 5:55 PM, Waldemar Horwat wrote:
>
>> On 03/14/2013 04:14 PM, Brendan Eich wrote:
>>> Andreas Rossberg wrote:
 On 14 March 2013 23:38, Brendan Eich  wrote:
> Andreas Rossberg wrote:
>> That leaves my original proposal not to have generator application
>> return an iterator, but only an iterable. Under that proposal, your
>> example requires disambiguation by inserting the intended call(s) to
>> .iterator in the right place(s).
> That's horribly inconvenient. It takes Dmitry's example:
>
>  function* enum(from, to) { for (let i = from; i<= to; ++i) yield i }
>
>  let rangeAsGenerator = enum(1, 4)
>  let dup = zip(rangeAsGenerator, rangeAsGenerator)  // Oops!
>
> which contains a bug under the Harmony proposal, to this:
>
>  function* enum(from, to) { for (let i = from; i<= to; ++i) yield i }
>
>  let rangeAsGenerator = enum(1, 4)
>  let dup = zip(rangeAsGenerator[@iterator](), 
> rangeAsGenerator[@iterator]())

 No, why? The zip function invokes the iterator method for you.
>>>
>>> Sure, but only if you know that. I thought you were advocating explicit 
>>> iterator calls.

I _have_ to know that, either way, because that is a fundamental part
of the function's contract. Its interface can be sketched as

  zip : (iterable, iterable) -> iterable

That implies that it takes care of invoking the iterator method of its argument.


>>> A call expression cannot be assumed to return a result that can be consumed 
>>> by some mutating protocol twice, in general. Why should generator functions 
>>> be special?
>>>
>>> I agree they could be special-cased, but doing so requires an extra 
>>> allocation (the generator-iterable that's returned).
>>>
>>> Meanwhile the Pythonic pattern is well-understood, works fine, and (contra 
>>> Dmitry's speculation) does not depend on class-y OOP in Python.
>>>
>>> I guess it's the season of extra allocations, but still: in general when I 
>>> consume foo() via something that mutates its return value, I do not expect 
>>> to be able to treat foo() as referentially transparent. Not in JS!
>>
>> Does for-of accept only iterables, only iterators, or both?  Presumably a 
>> function like zip would make a similar decision.  The problem is if the 
>> answer is "both".
>
> Strictly speaking for-of only accepts iterables since it always invokes the 
> @@iterator on the value to the RHS of the 'of' keyword.  For-of expects to 
> get a iterator back from the @@iterator call.
>
> Using informal interface descriptions this can be described as:
>
> interface  {
>@@iterator: ()-> 
> }
>
> interface  {
>next: () ->  
> }
>
> interface  {
>done: ,
>value: 
> }
>
> class Array implements  {...}
> class Map implements  {...}
> class Uint32Array implements  {...}
> etc.
>
> class "builtinArrayIterator" implements < iterator >+< iterable > {...}
> class "builtinMapIterator" implements < iterator >+< iterable > {...}
>
> The dual nature of the built-in iterators is nice because it allows 
> formulation like:
>
> for (v of myArray) ...  //iterate over an array using its default iterator
> for ([k,v] of myArray.entries())  ... //iterate over an array using an 
> alternative iterator as the iterable
> for (ev of (for (v of myArray) if (v&1==0) v)) ...  //the iterable is a 
> generator expression

None of these examples requires built-in iterators to also be
iterables, or generator results to also be iterators. For-of always
invokes @@iterator, so it's sufficient here if generator objects and
collections are plain iterables.


> My understanding of Andrea's concerns is that there is a hazard that somebody 
> might try to invoke @@iterator more than  once on an iterator that was also 
> an iterable.

My concern is that I _want_ to be able to invoke @@iterator more than
once _on any iterable_. Otherwise iterable-based abstractions like zip
_will not work_ with all (combinations of) iterables. Which would be a
real shame.

In other words, iterables should always be proper factories for
iterators (at least the ones provided by the language, obviously we
cannot make any guarantees whether user-defined ones properly
implement that contract).

Generator objects, as currently drafted, don't meet that goal (Python
precedence notwithstanding). In general, no object simultaneously
trying to be both an iterator and an iterable (returning itself)
sanely can. You don't get a duality but an inconsistency.

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

RE: Four static scoping violations in ES5 sloppy

[Domenic Denicola]

From: Sam Tobin-Hochstadt

> On Mon, Mar 18, 2013 at 8:40 AM, Andreas Rossberg  wrote:
>>
>> Nothing, but Sam probably meant to write:
>>
>> if (something_random()) xxx = 7;
>> xxx; // ReferenceError or not?
> 
> Right, I was confusing the problem this code describes, which is what I think 
> Mark meant, with the problem of the global object being on the scope chain.
> 
>>> It actually demonstrates how the situation is exactly the same with 
>>> *explicit* global variable creation. Strict mode does nothing to change the 
>>> result.
>>>
>>> Similarly, in case 3, the code could be `delete window.xxx` and we still 
>>> cannot statically predict whether there's a `ReferenceError` on the 
>>> subsequent line or not. Again, strict mode does not change the result.
>>
>> That is true, and the proper answer is that the global object should be on 
>> the above list as well. Not sure why Mark did not include it.
> 
> I believe that Mark would distinguish 1-4, which are fixed by strict mode, 
> from the global object, which is the remaining issue in ES5.

Last time this came up:

http://www.mail-archive.com/es-discuss@mozilla.org/msg18463.html

it was clarified that the global object is not a static scoping violation, 
since it's the top-most in the scope chain. Thus we know that every binding 
that's not in the nested function environments must be on the global object—or 
not exist.

That's the essence of my confusion. Cases 1 and 3 do not change things. That 
is, `xxx = 7` versus `window.xxx = 7` doesn't change where we determine `xxx` 
to be: it must be global (if it exists at all). Similarly, `delete xxx` versus 
`delete window.xxx` doesn't change that `xxx` must be global or not exist. And 
strict mode prohibits the former of these two forms, but doesn't prohibit the 
latter, and so seems to have no impact.

Now, if `with` and sloppy `eval` weren't removed, I could see the argument, at 
least for `delete`:

http://www.mail-archive.com/es-discuss@mozilla.org/msg18466.html

but with those two gone (i.e. with 2 and 4 gone), 1 and 3 seem to not matter.

> But only Mark can answer this for sure.

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

Re: Four static scoping violations in ES5 sloppy

[Sam Tobin-Hochstadt]

On Mon, Mar 18, 2013 at 8:40 AM, Andreas Rossberg  wrote:
>
> Nothing, but Sam probably meant to write:
>
> if (something_random()) xxx = 7;
> xxx; // ReferenceError or not?

Right, I was confusing the problem this code describes, which is what
I think Mark meant, with the problem of the global object being on the
scope chain.

>> It actually demonstrates how the situation is exactly the same with 
>> *explicit* global variable creation. Strict mode does nothing to change the 
>> result.
>>
>> Similarly, in case 3, the code could be `delete window.xxx` and we still 
>> cannot statically predict whether there's a `ReferenceError` on the 
>> subsequent line or not. Again, strict mode does not change the result.
>
> That is true, and the proper answer is that the global object should
> be on the above list as well. Not sure why Mark did not include it.

I believe that Mark would distinguish 1-4, which are fixed by strict
mode, from the global object, which is the remaining issue in ES5.
But only Mark can answer this for sure.

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

Re: Four static scoping violations in ES5 sloppy

[Andreas Rossberg]

On 18 March 2013 13:28, Domenic Denicola  wrote:
> On Mar 18, 2013, at 7:54, "Sam Tobin-Hochstadt"  wrote:
>
>> On Sun, Mar 17, 2013 at 11:44 PM, Domenic Denicola
>>  wrote:
>>>
>>> 1. implicit global variable creation
>>> 2. `with`
>>> 3. `delete`ing free variables
>>> 4. `eval` introducing local bindings
>>>
>>> 2 and 4 make perfect sense, but I don't understand how 1 and 3 interfere 
>>> with static scoping. In particular, given a language with no `with` and 
>>> with ES5-strict semantics for `eval`, I was unable to contrive scenarios 
>>> where implicit global variable creation or `delete`ing a free variable 
>>> introduced an ambiguity in the scope chain that prevented static knowledge 
>>> of what an identifier referred to.
>>>
>>> Does anyone have any idea how 1 and 3 interfere with static scoping?
>>
>> The point is that given these features, you can't predict statically
>> whether a variable reference is bound to a global variable, or is
>> unbound and will produce a ReferenceError.
>>
>> Here's case 1:
>>
>> if (something_random()) window.xxx = 7;
>> xxx; // ReferenceError or not?
>>
>> And here's case 3:
>>
>> if (something_else_random()) delete xxx;
>> xxx; // ReferenceError or not?
>
> Thanks, but what does your example for case 1 have to do with implicit global 
> variable creation?

Nothing, but Sam probably meant to write:

if (something_random()) xxx = 7;
xxx; // ReferenceError or not?

> It actually demonstrates how the situation is exactly the same with 
> *explicit* global variable creation. Strict mode does nothing to change the 
> result.
>
> Similarly, in case 3, the code could be `delete window.xxx` and we still 
> cannot statically predict whether there's a `ReferenceError` on the 
> subsequent line or not. Again, strict mode does not change the result.

That is true, and the proper answer is that the global object should
be on the above list as well. Not sure why Mark did not include it.

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

Re: Four static scoping violations in ES5 sloppy

[Domenic Denicola]

On Mar 18, 2013, at 7:54, "Sam Tobin-Hochstadt"  wrote:

> On Sun, Mar 17, 2013 at 11:44 PM, Domenic Denicola
>  wrote:
>> 
>> 1. implicit global variable creation
>> 2. `with`
>> 3. `delete`ing free variables
>> 4. `eval` introducing local bindings
>> 
>> 2 and 4 make perfect sense, but I don't understand how 1 and 3 interfere 
>> with static scoping. In particular, given a language with no `with` and with 
>> ES5-strict semantics for `eval`, I was unable to contrive scenarios where 
>> implicit global variable creation or `delete`ing a free variable introduced 
>> an ambiguity in the scope chain that prevented static knowledge of what an 
>> identifier referred to.
>> 
>> Does anyone have any idea how 1 and 3 interfere with static scoping?
> 
> The point is that given these features, you can't predict statically
> whether a variable reference is bound to a global variable, or is
> unbound and will produce a ReferenceError.
> 
> Here's case 1:
> 
> if (something_random()) window.xxx = 7;
> xxx; // ReferenceError or not?
> 
> And here's case 3:
> 
> if (something_else_random()) delete xxx;
> xxx; // ReferenceError or not?

Thanks, but what does your example for case 1 have to do with implicit global 
variable creation? It actually demonstrates how the situation is exactly the 
same with *explicit* global variable creation. Strict mode does nothing to 
change the result.

Similarly, in case 3, the code could be `delete window.xxx` and we still cannot 
statically predict whether there's a `ReferenceError` on the subsequent line or 
not. Again, strict mode does not change the result.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Four static scoping violations in ES5 sloppy

[Sam Tobin-Hochstadt]

On Sun, Mar 17, 2013 at 11:44 PM, Domenic Denicola
 wrote:
>
> 1. implicit global variable creation
> 2. `with`
> 3. `delete`ing free variables
> 4. `eval` introducing local bindings
>
> 2 and 4 make perfect sense, but I don't understand how 1 and 3 interfere with 
> static scoping. In particular, given a language with no `with` and with 
> ES5-strict semantics for `eval`, I was unable to contrive scenarios where 
> implicit global variable creation or `delete`ing a free variable introduced 
> an ambiguity in the scope chain that prevented static knowledge of what an 
> identifier referred to.
>
> Does anyone have any idea how 1 and 3 interfere with static scoping?

The point is that given these features, you can't predict statically
whether a variable reference is bound to a global variable, or is
unbound and will produce a ReferenceError.

Here's case 1:

if (something_random()) window.xxx = 7;
xxx; // ReferenceError or not?

And here's case 3:

if (something_else_random()) delete xxx;
xxx; // ReferenceError or not?

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

Re: Comments on “Making Built-in Objects Subclassable”

[Herby Vojčík]

Herby Vojčík wrote:



Axel Rauschmayer wrote:

A few more thoughts:

- This marks the end of prototypal inheritance in JavaScript (not
complaining, just stating a fact). Putting @@create in constructors C
makes a lot of sense, but it could, in principle, also be put into
instance prototypes C.prototype. Then Object.create(proto) could use
@@create to create the instance whose prototype is proto.


The identifier create is probably used in lots of other places, so this
is non-starter, but if not, it could be simply reused, so that:

Ctr.create(proto, [descriptors])

does

newobj = Ctr[@@create]();
newobj.__proto__ = proto;
Object.defineProperties(newobj, descriptors);


Sorry for replying to myself, but another possibility is to add proto 
and descriptors parameters to IIRC parameterless @@create. Object.create 
would thus just point to Object[@@create] and others could be create 
similarly: Array[@@create](myprototype, mydescriptors);



It is semantically compatible with what Object.create does now.
In fact, if somewhere inside implementation of Object.create one would
use "this[@@create]" to create new instance, and it was moved to
Function.prototype, it could be used as is.


Axel


Herby

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

Re: Comments on “Making Built-in Objects Subclassable”

[Herby Vojčík]

Axel Rauschmayer wrote:

A few more thoughts:

- This marks the end of prototypal inheritance in JavaScript (not
complaining, just stating a fact). Putting @@create in constructors C
makes a lot of sense, but it could, in principle, also be put into
instance prototypes C.prototype. Then Object.create(proto) could use
@@create to create the instance whose prototype is proto.


The identifier create is probably used in lots of other places, so this 
is non-starter, but if not, it could be simply reused, so that:


  Ctr.create(proto, [descriptors])

does

  newobj = Ctr[@@create]();
  newobj.__proto__ = proto;
  Object.defineProperties(newobj, descriptors);

It is semantically compatible with what Object.create does now.
In fact, if somewhere inside implementation of Object.create one would 
use "this[@@create]" to create new instance, and it was moved to 
Function.prototype, it could be used as is.



Axel


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

Comments on “Making Built-in Objects Subclassable”

[Axel Rauschmayer]

A few more thoughts:

- This marks the end of prototypal inheritance in JavaScript (not complaining, 
just stating a fact). Putting @@create in constructors C makes a lot of sense, 
but it could, in principle, also be put into instance prototypes C.prototype. 
Then Object.create(proto) could use @@create to create the instance whose 
prototype is proto.

- I would love to have a @@postConstruct method (similar to @@create) that is 
invoked after all constructors are done with initialization. Use case: freeze 
an instance or make it non-extensible.

- Slide 24: marking objects as initialized in the root of a class hierarchy 
looks suspicious to me (the constructors are not done initializing, yet!). 
Doing it in something like @@postCreate might make more sense.

Axel

-- 
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

Re: Constructors need to be able to recognize uninitalized instances(?)

[Herby Vojčík]

I think the idea of detecting if you have initialized or noninitialized 
instance at runtime is very unhappy idea.


You know when it is called as an initializer (2, 4 below) and when not 
(1 below). 3 below is legacy way of doing super - it can be simply replaced.


And there is also no breaking compatibility cost - so far, there was no 
API to distinguish this; so once it is added, it can be safely specified 
that "initializer" context is only 2 and 4.


Herby

Axel Rauschmayer wrote:

[Referring to Allen’s slides:
http://wiki.ecmascript.org/lib/exe/fetch.php?id=meetings%3Ameeting_jan_29_2013&cache=cache&media=meetings:subclassing_builtins.pdf

]

Is this really true?

I can see four ways of invoking a constructor function C:

1. As a function: C(...)
2. Via `new`: new C(...)
3. Via `call`: C.call(this, ...)
4. Via `super`, in a sub-instance, as a method (similar to #3):
super.constructor(...)

C[@@create] is only invoked during #2 (by the `new` operator). Thus, the
constructor’s role is always: set up an uninitialized instance. You
could add a check against an instance being initialized twice, but that
doesn’t seem to be what the slides are about.

The slides mention one use case: What if you want to have a function Foo
that can be either called as a function or as a constructor? You can’t
detect the difference if Foo is inside a namespace object. That is, you
want to distinguish #1 from all others, but #1 could happen to a
namespaced C. Observations:

– Does recognizing whether `this` is initialized really help here? Isn’t
it more about checking whether `this` is an instance of C?

– I’ve always considered this to be more of an anti-pattern for
non-builtin code. Thus, it seems useful to support a check, but only so
that namespaced constructors can avoid accidentally polluting the
namespace object.

– Won’t namespace objects go away with modules?

Thanks!

Axel

--
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

Re: Where is it specified that new objects are empty, if it is?

[Andreas Rossberg]

On 16 March 2013 00:00, Kevin Reid  wrote:
> I'm doing a little maintenance on SES. Chrome has recently added a new
> odd behavior:
>
>> var o = Object.create(null);
>> Object.getOwnPropertyNames(o)
> []
>> Object.getOwnPropertyDescriptor(o, '__proto__');
> Object {value: null, writable: true, enumerable: false, configurable: false}

That seems to be the old odd behaviour, not the new. On V8 trunk you
get 'undefined' for the latter.

In the process of adopting the new __proto__ semantics, we have
recently changed it to be a magic data property on Object.prototype.
In a next step, we will make it a proper JS accessor property.

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