Controlling DontEnum (was: ES4 draft: Object)

Lars Hansen lhansen at adobe.com
Thu Mar 13 09:47:03 PDT 2008


Trying to sum up in order to make progress.  Let me all know
what you think.

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.

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.

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.

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

As for an interface, there are four options.  We can have
three independent arguments (booleans that default to false):

  o.__createProperty__("foo",true,true,true)

or we can have a bitmask of flags, C-style (with the
flag constants defined on Object, probably -- obviously a
danger of introducing new names):

  o.__createProperty__("foo",Object.DontEnum|Object.DontDelete)

or we can pass flags as strings:

  o.__createProperty__("foo","DontEnum","DontDelete")

or we can pass an object with named properties:

  o.__createProperty__("foo",{dontEnum:true,dontDelete:true})

(Let's avoid restarting the discussion about named arguments
in this thread, even if we'd obviously benefit from such a
mechanism.)

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

Notes.

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

  * The above has no obvious bearing on what's done about
    enumerating namespaced properties.

  * The above morphs easily to Object.__createProperty__ or
    similar, if that's desired; I'm entirely agnostic.

  * The updated form of propertyIsEnumerable is removed from
    the Object class in any case.

--lars

> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org 
> [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Kris Zyp
> Sent: 11. mars 2008 23:13
> To: Brendan Eich
> Cc: Neil Mix; Peter Hall; es4-discuss at mozilla.org
> Subject: Re: Controlling DontEnum (was: ES4 draft: Object)
> 
> 
> >> Object.prototype.__setPropertyWithAttributes__(name, 
> value, dontEnum:
> >> boolean, readOnly: boolean, dontDelete: boolean);
> >
> > Only if you cannot change an existing properties attribute, 
> or delete  
> > an existing property and create a new one with the same 
> name. Those  
> > cases would have to fail. A false return is not a fail-stop  
> > condition, so an exception might be better.
> 
> Yes, I agree.
> 
> > And yeah, the  lack of named parameters hurts call-site readability.
> 
> Yeah, I took ugly and maybe it even uglier, didn't I :). 
> Obviously one could do better...
> 
> Kris 
> 
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
> 



More information about the Es4-discuss mailing list