ES4 draft LAST CALL: Object

Lars Hansen lhansen at
Thu Mar 20 19:45:32 PDT 2008

> -----Original Message-----
> From: Mark S. Miller [mailto:erights at] 
> Sent: 20. mars 2008 18:05
> To: Lars Hansen
> Cc: es4-discuss at
> Subject: Re: ES4 draft LAST CALL: Object
> 2008/3/20 Lars Hansen <lhansen at>:
> > The only substantive change since the previous draft is a 
> rename of  
> > __createProperty__ to __defineProperty__ in order to mirror 
> the names  
> > __defineSetter__ and __defineGetter__.  The latter two are 
> not in ES4  
> > but in some browsers and could be expanded to accept 
> additional flags 
> > to  control enumerability and so on.
> * I still prefer __defineProperty__ (under whatever name) to 
> be a static property rather than an instance property, so 
> that an object can reliably perform this operation on itself 
> without worrying about whether it is shadowed by an own 
> property of the same name. As an instance method, to protect 
> against this shadowing, one must instead
> write:
>, ...)
> This is so much less convenient than the unsafe
>    this.__defineProperty__(...)
> that people will get sloppy.

Another interesting point.  Probably, the intrinsic __defineProperty__
method ought to be declared 'final' at a minimum, it does seem
somewhat senseless to allow it to be overridden.

At that point, 'this.intrinsic::__defineProperty__(...)' is always
predictable, though wordier than Object.__defineProperty__(...) would

I can't imagine anyone using the longer version you provide above.
How unsafe should I feel?  (I'm not being sarcastic, for the record.)

> Part of programming language design is to make the safer way
> also generally be the easier way. The innumerable places where
>, ...)
> were or needed to be written should have already taught these lessons.
> * I also continue to think that any of the other alternatives 
> for parameterizing __defineProperty__ were more readable than 
> a bunch of positional flag parameters whose order will often 
> be mis-remembered.
> My favorite remains a C-style or-ing of bit flags, with 
> manifest constants defining the bits.

I suspect "often" is overstating the case, but I'm not really arguing,
other alternatives would be somewhat easier to use.  They would also
break existing patterns, and IMO that's where the balance comes in.


More information about the Es4-discuss mailing list