ES4 draft: Object

Lars Hansen lhansen at adobe.com
Mon Mar 10 18:10:38 PDT 2008


> -----Original Message-----
> From: Waldemar Horwat [mailto:waldemar at google.com] 
> Sent: 10. mars 2008 18:50
> To: Lars Hansen
> Cc: es4-discuss at mozilla.org
> Subject: Re: ES4 draft: Object
> 
> > intrinsic function propertyIsEnumerable(name: EnumerableId, flag: 
> > (boolean|undefined) = undefined): boolean
> 
> I too find the second parameter here abhorrent.  Please find 
> another way to solve it (Brendan's namespace idea maybe) or 
> remove this feature altogether.

The feature was approved by the WG and solves a practical problem.
If another way to solve this practical problem is proposed (in a
more structured form than in the ongoing discussion) and finds favor
with the WG, then fine -- of course we can replace it.  Until then,
this feature stays as it is until the WG can be convinced that it
needs to be removed.  Personally I think that "it is ugly/abhorrent"
is a weak basis on which to remove the current feature.

> How does property lookup deal with properties indexed by 
> numbers that are not int or uint?  toEnumerableId converts 
> them to strings, but the Vector proposal indicated that 
> vectors don't.

The intrinsic::hasOwnProperty and intrinsic::propertyIsEnumerable 
methods on Object require EnumerableId parameters, and no conversion
happens automatically when they are called (there should be no
automatic conversion to union types, even from a number to a number
in the type).  So programs trying to call the intrinsic methods on 
doubles (say) will receive errors.  This is true independent of
Vector.

The prototype methods inherited from Object perform conversions
explicitly, but can be overridden in Vector to prevent the 
conversion.  Ergo the hasOwnProperty and propertyIsEnumerable
methods on Vector should be able to handle arbitrary names,
and should return "false" for all property names that are
numbers not in the uint range -- if that's what we think is the
desired behavior.

That said, you raise a good point and I don't think the story is
fully coherent yet.  Certainly we don't have a working prototype
of this.

(And yet another point is that I expect that the int and uint types
are not going to be in the final language and that some of the
machinery in Object will have to be rethought as a consequence
of that change.)

--lars



More information about the Es4-discuss mailing list