Controlling DontEnum (was: ES4 draft: Object)

liorean liorean at gmail.com
Thu Mar 13 13:31:16 PDT 2008


On 13/03/2008, Lars Hansen <lhansen at adobe.com> wrote:
>  Since our method is creating a new property and not setting
>  one, I suggest __createProperty__ as the most appropriate
>  name, so I'm going to use that below.

Sounds perfectly reasonable to me.

>  I still think it may be right that properties in non-public
>  namespaces should not be enumerated, but I also think that's
>  orthogonal to the discussion that's going on here, about
>  dynamic properties and their attributes.  We've pretty much
>  decided (ticket #233 has some of the discussion) that for
>  future compatibility there ought to be a difference between
>  fixture properties and DontDelete "dynamic" properties.  So
>  dynamic properties have at least one attribute bit like they
>  do in ES3 (for deletability).  Consequently, they might as
>  well have all the ES3 bits: for enumerability and writability.

For ES4, shouldn't this function also take a type binding?

>  Ergo, let's assume that we are not finessing more than we
>  have to, and dynamic properties have all these attribute bits.
>  I don't know why __createProperty__ should not be able to
>  set all of these.

Neither can I.

>  (They're not independent, ReadOnly implies DontDelete.)
>
>  __createProperty__ should throw an exception (TypeError?) if
>  the property already exists on the object or would shadow a
>  ReadOnly property, a la [[CanPut]], or if the object is not
>  dynamic.  It should probably throw an exception if its
>  arguments are not consistent (ReadOnly && !DontDelete).

If ReadOnly is specified, is there even a reason to look at DontDelete?

>  Pesonally I like the strings approach, but the only interface
>  among these four that has good compile-time checking is the
>  first one, so I'm going to propose that we use that one,
>  with dontEnum as the first flag, dontDelete as
>  the second, and readOnly as the third (based on a guess about
>  the frequency of use).  Thus on Object.prototype and as an
>  intrinsic propety on Object instances:
>
>   function __createProperty__(name:EnumerableId,
>                               dontEnum:boolean=false,
>                               dontDelete:boolean=false,
>                               readOnly:boolean=false): void

ReadOnly would need to be instanciated at the same time, no? And you
probably want to be able to specify a type binding for ES4.

>   * The above does not preclude complementary declarative
>     mechanisms in ES4 (but not in ES3.1 obviously)

Good to hear, because I still want to see something that can be used
in object literals and property declarations.
-- 
David "liorean" Andersson



More information about the Es4-discuss mailing list