Re: A new function name property proposal
On 22/11/2012, at 09:38, Brendan Eich wrote: Brandon Benvie wrote: I don't know the specific reasoning behind it. I guess the idea is that a function is declared in a maximum of one scope. For the declaration it's the outer scope, for a named function expression it's a static scope that sits between the outer scope and the (during execution of the function) inner scope. Also just to clarify, the above isn't something I'm proposing. It's how things currently work. Right. I think Jorge may be concerned that naming a function does not always relieve the need for arguments.callee. But that's only true in a function declaration, which is inherently named, as you showed -- and only if one then overwrites the name in its scope. So don't do that. Fear that someone else might means you are in the global scope, which means that instead of using such a hard case to justify arguments.callee, you ought to modularize with an IIFE or (in due course) ES6 module. To clarify, I wasn't trying to justify arguments.callee. don't do that is a solution, for this and for many other WTFs and footguns... But, isn't the NFEs' way the Right Way to do it? Do we want this footgun in function declarations? Why? Is there any reason for not removing it? (Other than because it's a corner case?) Cheers, -- Jorge. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
In ES6 methods (both in classes and in object literals) don't create any binding at all for their name. Would you say that's better or worse? As far as changing the binding behavior of names for existing function declaration and expression forms...it'd be fiddling with something that has (I think) always been part of JS and is a core mechanic and would have a widely felt impact if changed. It's just not possible to change it even if it was desired. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
Jorge Chamorro wrote: On 22/11/2012, at 09:38, Brendan Eich wrote: Brandon Benvie wrote: I don't know the specific reasoning behind it. I guess the idea is that a function is declared in a maximum of one scope. For the declaration it's the outer scope, for a named function expression it's a static scope that sits between the outer scope and the (during execution of the function) inner scope. Also just to clarify, the above isn't something I'm proposing. It's how things currently work. Right. I think Jorge may be concerned that naming a function does not always relieve the need for arguments.callee. But that's only true in a function declaration, which is inherently named, as you showed -- and only if one then overwrites the name in its scope. So don't do that. Fear that someone else might means you are in the global scope, which means that instead of using such a hard case to justify arguments.callee, you ought to modularize with an IIFE or (in due course) ES6 module. To clarify, I wasn't trying to justify arguments.callee. don't do that is a solution, for this and for many other WTFs and footguns... But, isn't the NFEs' way the Right Way to do it? Do what? Function declarations are useful too. They hoist so you can write them in top-down order and call in any order from top-level code. You can't do this with vars initialized with function expressions. Do we want this footgun in function declarations? What footgun? People don't overwrite function declarations' bindings by accident much, if at all. I can't remember hearing of this lately, although it can happen when loading libraries where a common name is used by two libraries. Programmers do intentionally replace a function's name in its scope, e.g. to auto-memoize. Why? Is there any reason for not removing it? (Other than because it's a corner case?) Removing what? The writable binding created by a function declaration? That's required by backward compatibility (e.g. the memoization pattern). /be Cheers, ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
New ES6 draft now available
The Nov. 22, 2012 draft of the ES6 specificaiotn is now at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Here are the release notes: Changes marked as “Rev 12” This is a major revision that takes the first step at reforming the internal Meta-Object Protocol (the “internal methods”) and extending it to support Proxies. Quite a bit of material has moved within the document. The overall document organization is in a state of flux and some sections will be moved in the future. For now, somethings have been temporarily left in their old locations to preserve change markup relative to ES 5.1 that might otherwise get lost. Changes include: • Reorganized Chapter 8 into separate language type and specification type sub sections • Added Symbol property keys to the definition of the Object Type. terminology migration from talking about “property names” to “property keys”. • Restructured 8.6.2 (now 8.1.6.2) as the abstract interface definition of the internal object MOP. eliminated Table 9 (Internal props of only some objects) and distribute related material to definitions of specific object forms. Moved discussion of internal method invariants plus invariant enforced by proxies into separate place order subsection. This needs a complete rewrite to clearly define the actual internal methods invariants. • MOP changes: Added [[GetInheritance]]/[[SetInheritance]] as internal methods for accessing [[Prototype]] internal prototype chain. Added [[[IsExtensible]]/[[PreventExtensions]]. Replaced [[Get]]/[[Put]] with [[GetP]]/[[SetP]]. At some point we may be able to rename these as [[Get]]/[[Set]]. Eliminated [[GetProperty]], [[CanPut]], [[HasProperty]], [[DefaultValue]]. Added Keys, [[OwnPropertyKeys]], [[Freeze]], [[Seal]], [[IsFrozen]], [[IsSealed]]. • [[DefaultValue]] now part of ToPrimitive with a possible dispatch through a @@ToPrimitive symbol keyed method on objects. Define a @@ToPrimitive method on Date.prototype to take care of special date [[DefaultValue]] rules. • As part of “proto climbing” reform refactored GetValue and PutValue to directly incorporate the logic for property references on primitive values. Eliminated special [[Put]] and [[Get]] for primitive bases. • Eliminated all “strict” arguments to internal methods that were used to request trapping in strict mode”. All such methods now always return true/false success status. It’s up to the called (usually via a convenience function) to throw on failure. • Section 8.3-8.5 now provided the concrete implementation of the MOP interface for all ordinary and exotic object forms defined in the specification. this will eventually move into a new top level section following the current section 10. • Defined Symbol objects as a kind of exotic object. Its internal methods make it stateless and immutable. • In 9.3 added a number of convenience functions that operate at the level of the generic object MOP. These can be thought of as generic “derived” operations that will work with any kind of object. They are now used throughout the specification. • Added Table 25 (incomplete) in 10.3 to define the “intrinsic objects” of a code realm • instanceof operator no longer uses an internal method. Instead, extensible via a @@hasInstance symbol-keyed regular method. • Restated most Object.* reflection functions to delegate to corresponding MOP internal method. • Defined all of the functions in the @Reflect module corresponding to MOP internal operations. • Resolved bugs: 982, 979, 978, 973, 971-969, 966, 960, 958-956, 954-952, 950, 948-945, 943-936, 934-925, 923, 920-914, 912-904, 902-883, 881-873, 870-853, 851-839, 837-818, 808, 785, 672, 591, 400, 150, 100___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 draft now available
Allen Wirfs-Brock wrote: The Nov. 22, 2012 draft of the ES6 specificaiotn is now at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Clicking pdf with change markup only for this revision yields Not Found. -Michael ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: New ES6 draft now available
fixed On Nov 23, 2012, at 10:24 AM, Michael Dyck wrote: Allen Wirfs-Brock wrote: The Nov. 22, 2012 draft of the ES6 specificaiotn is now at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts Clicking pdf with change markup only for this revision yields Not Found. -Michael ___ 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: A new function name property proposal
On 23/11/2012, at 18:47, Brendan Eich wrote:
Jorge Chamorro wrote:
On 22/11/2012, at 09:38, Brendan Eich wrote:
Right. I think Jorge may be concerned that naming a function does not
always relieve the need for arguments.callee. But that's only true in a
function declaration, which is inherently named, as you showed -- and only
if one then overwrites the name in its scope.
So don't do that. Fear that someone else might means you are in the global
scope, which means that instead of using such a hard case to justify
arguments.callee, you ought to modularize with an IIFE or (in due course)
ES6 module.
To clarify, I wasn't trying to justify arguments.callee.
don't do that is a solution, for this and for many other WTFs and
footguns...
But, isn't the NFEs' way the Right Way to do it?
Do what?
Bind the name inside the function *too*.
Function declarations are useful too. They hoist so you can write them in
top-down order and call in any order from top-level code.
And hoisting is handy, I use it a lot and can't live without it.
You can't do this with vars initialized with function expressions.
Of course, if they were interchangeable we'd simply write var x= function x ()
{}; and done.
Do we want this footgun in function declarations?
What footgun?
The footgun (1) is to have the name bound *only* in the outer scope.
People don't overwrite function declarations' bindings by accident much, if
at all.
I can't remember hearing of this lately, although it can happen when loading
libraries where a common name is used by two libraries.
Yes it's a corner case.
Programmers do intentionally replace a function's name in its scope, e.g. to
auto-memoize.
Oh, how does that work? I've written memoizers but never needed to overwrite a
name.
Why?
Is there any reason for not removing it? (Other than because it's a corner
case?)
Removing what?
The footgun (1)
The writable binding created by a function declaration? That's required by
backward compatibility (e.g. the memoization pattern).
The -outer- writable binding isn't the problem, the problem is the lack of
binding in the inner scope. Is there a reason for not having it?
--
Jorge.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A new function name property proposal
Jorge Chamorro wrote: On 23/11/2012, at 18:47, Brendan Eich wrote: Jorge Chamorro wrote: On 22/11/2012, at 09:38, Brendan Eich wrote: Right. I think Jorge may be concerned that naming a function does not always relieve the need for arguments.callee. But that's only true in a function declaration, which is inherently named, as you showed -- and only if one then overwrites the name in its scope. So don't do that. Fear that someone else might means you are in the global scope, which means that instead of using such a hard case to justify arguments.callee, you ought to modularize with an IIFE or (in due course) ES6 module. To clarify, I wasn't trying to justify arguments.callee. don't do that is a solution, for this and for many other WTFs and footguns... But, isn't the NFEs' way the Right Way to do it? Do what? Bind the name inside the function *too*. That's not a compatible change, and unmotivated by any actual foot damage. Do we want this footgun in function declarations? What footgun? The footgun (1) is to have the name bound *only* in the outer scope. We need evidence this is a real hazard. Otherwise you're assuming a conclusion and using a circular argument of sorts: that lack of the inner unwritable name binding is a problem requiring just that solution. People don't overwrite function declarations' bindings by accident much, if at all. I can't remember hearing of this lately, although it can happen when loading libraries where a common name is used by two libraries. Yes it's a corner case. Ok, so what's the non-corner foot-damaging case? Programmers do intentionally replace a function's name in its scope, e.g. to auto-memoize. Oh, how does that work? I've written memoizers but never needed to overwrite a name. http://osteele.com/posts/2006/04/one-line-javascript-memoization Works on global functions as well prototype methods. The writable binding created by a function declaration? That's required by backward compatibility (e.g. the memoization pattern). The -outer- writable binding isn't the problem, the problem is the lack of binding in the inner scope. Is there a reason for not having it? Again, introducing such a binding is an incompatible change. I don't know what it might break, but I doubt anyone wants the risk. Also there's overhead in making such an inner binding -- another reason implementors won't go there. Finally, you have not justified this change by any evidence it addresses a real, observed hazard. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
