using Private name objects for declarative property definition.

Brendan Eich brendan at mozilla.com
Mon Jul 11 09:32:15 PDT 2011


On Jul 11, 2011, at 9:25 AM, Allen Wirfs-Brock wrote:

> On Jul 10, 2011, at 6:58 PM, Brendan Eich wrote:
> 
>> On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:
>> 
>>> Why not a non-writable,non-enumerable non-configurable data property on Function.prototype.
>> 
>> We're talking about isGenerator, right? There is no Generator constructor, no shadowing opportunity. Function can create a generator if yield occurs in the body string.
> 
> Oops, forgot we were talking about isGenerator.  So why not internally defined
> 
> const  __generatorProto__ = Object.create(Function.prototype, {isGenerator: {value: true}});
> 
> and specify that function containing yield are created as if by:
>     __generatorProto__ <| function (...) {...yield...}
> 
> In other words, generator functions have a different [[Prototype]] than regulator functions.

There's no point. We haven't ever had a request for this. It requires polluting the global object (or some object) with a property (even adding a private name requires adding a public property naming the private name object).


> Alternatively, isGenerator could be a method, but that's the the point here.

That's the point we're arguing about, yes.

The method allows object-detection, which helps. It's ad-hoc but web JS has versioned itself based on object detection far better than on other, _a priori_ grand plans (Accept: headers, e.g.).

/be


More information about the es-discuss mailing list