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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
