The thing that worries me about configurability is that it allows something to become an accessor. I was following the path of "prototype" when deciding on non-configurability for "name". Essentially: preventing arbitrary code from executing when accessing this thing.
I'm not married to this restriction, I just wanted to following real world implementations as closely as possible. If implementors have no issue then I don't. But figured every difference between existing implementations and the spec was an additional barrier to my idea becoming realistic reality. On Aug 30, 2013, at 9:34 PM, Brendan Eich <[email protected]> wrote: > Mark and I discussed this privately a while back. We would rather use the > same attribute pair for both. Is non-writable configurable ok? I argued that > for name it is onerous to require Object.defineProperty calls, e.g., from > Cappuccino when compiling Objective-J into JS, to fix up every function's > name to tell its Obj-J pathname. But you wrote the name proposal -- you > should weigh in and even call this shot! > > /be > >> Brandon Benvie <mailto:[email protected]> >> August 30, 2013 11:39 AM >> Part of the function name proposal submitted would make "name" writable but >> not configurable, which is the inverse of the current spec for "length" >> being configurable but not writable. Seems there needs to be some discussion >> on what attributes should be where. >> >> On Aug 30, 2013, at 7:36 PM, "Mark S. Miller" <[email protected] >> <mailto:[email protected]>> wrote: >> >>> Cool. In that case we have more freedom. In any case, we should give both >>> of these the same attributes. >>> >>> >>> On Fri, Aug 30, 2013 at 10:34 AM, Claude Pache <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> Le 30 août 2013 à 18:54, "Mark S. Miller" <[email protected] >>> <mailto:[email protected]>> a écrit : >>> >>> > It seems we have legacy saying that "name" should be writable. >>> > >>> >>> Really? Just tried in the console of the latest stable versions >>> of Firefox, Safari, Chrome and IE: >>> >>> ``` >>> Object.getOwnPropertyDescriptor(function() {}, 'name') >>> ``` >>> >>> Firefox, Safari and Chrome: `{value: "", writable: false, >>> enumerable: false, configurable: false}` >>> IE: `undefined` >>> >>> —Claude >>> >>> >>> >>> >>> -- >>> Cheers, >>> --MarkM >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] <mailto:[email protected]> >>> https://mail.mozilla.org/listinfo/es-discuss >> Brendan Eich <mailto:[email protected]> >> August 30, 2013 9:34 AM >> Allen probably could use a bug on file at bugs.ecmascript.org -- anyone? >> >> /be >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> Claude Pache <mailto:[email protected]> >> August 30, 2013 5:35 AM >> The `uncurryThis` metafunction, given as example in [1], needs to correct >> the length of a function produced by `bind`. Simplified version: >> >> ``` >> uncurryThis = f => Function.protytpe.call.bind(f) // uncurryThis(f).length >> == 1 instead of f.length + 1 >> ``` >> >> So, yes, `bind` should produce functions with mutable length. >> >> —Claude >> >> [1] http://www.mail-archive.com/[email protected]/msg21786.html >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> Brandon Benvie <mailto:[email protected]> >> August 30, 2013 3:54 AM >> The latest spec revision makes the function "length" property configurable >> (section 8.3.16.6). Function.prototype.bind (15.3.3.5) still produces >> functions with non-configurable "length", however. I think this may be an >> oversight, but I'm not sure. >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
