Controlling DontEnum (was: ES4 draft: Object)

Lars Hansen lhansen at adobe.com
Thu Mar 13 10:47:43 PDT 2008


> -----Original Message-----
> From: Kris Zyp [mailto:kris at sitepen.com] 
> Sent: 13. mars 2008 11:27
> To: Lars Hansen; es4-discuss at mozilla.org
> Subject: Re: Controlling DontEnum (was: ES4 draft: Object)
> 
> > 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
> I thought that this only made sense in conjunction with 
> Neil's suggestion of providing the value at the same time. If 
> you create a readonly property, how are you supposed to set 
> the value otherwise? Shouldn't it be:
> function __createProperty__(name:EnumerableId,
>                                 value,
>                                 dontEnum:boolean=false,
>                                 dontDelete:boolean=false,
>                                 readOnly:boolean=false): void

Simple oversight.  You are right.

> And if readOnly implied dontDelete, I would have guessed 
> readOnly to be a little more frequent than dontDelete, but of 
> course that is just a guess.

ReadOnly implies DontDelete because ReadOnly doesn't make sense without
DontDelete, but my guess (based on no data at all, just how I write
code) is that undeletable mutable state is desired slightly more often
than undeletable immutable state.  (Also, if you're asking for
ReadOnly=true then you're forced to state DontDelete=true, reminding you
of this fact.  My hunch is that this order slightly reduces the scope
for error, which would be greater if you could state ReadOnly=true
without being forced to think about DontDelete in the last argument
position.)

All that said, I like Yuh-Ruey Chen's variation, where flags are tokens
extracted from Object but passed individually following the value; if we
ever end up with strong type checks for rest arguments (a feature that
is a little wobbly at present) then the API would look like this:

  class Object {
    static const READ_ONLY : AttrToken = new AttrToken;
    static const DONT_ENUM : AttrToken = new AttrToken;
    static const DONT_DELETE : AttrToken = new AttrToken;    

    intrinsic function __createProperty__(name, value, ...bits :
[AttrToken]) ...
  }

for some opaque non-user-accessible class AttrToken.

--lars



More information about the Es4-discuss mailing list