using Private name objects for declarative property definition.

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Jul 11 10:25:21 PDT 2011


On Jul 11, 2011, at 9:32 AM, Brendan Eich wrote:

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


I don't think we or anybody else has really explored the extensibility implications of generator functions so it isn't surprising that there have been no requests.

Certainly there is no need to add any new globals to support a distinct prototype for generator functions. Strictly speaking there wouldn't even have to be a property on Function to access it as it would be a built-in object that is accessed internally when a generator is created.  However, I do think it would be useful make it accessible via something like Function.generatorPrototype.   I don't see that adding such a property as undesirable pollution.



> 
> 
>> Alternatively, isGenerator could be a method, but that's the the point here.
> 
> That's the point we're arguing about, yes.

I think that the factoring of the prototype hierarchy is largely distinct issue but, yes, there is some overlap in that a use of a data property for this particular tagging requires a separate prototype object for generators. 

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

Function.generatorPrototype as described above would also support object-detection.

In general, how far to you think we can push a "all new features have to be object-detectable" requirement.  Do we need to be able to object-detect <|.  How about rest and spread, or de-structuring?  We are going to use non-eval detectability as a ECMAScript extension design criteria then maybe we do need a less ad-hoc scheme for feature detection.  It wouldn't have to be all that grand...

allen




More information about the es-discuss mailing list