defineProperty/getProperty design sketch

Brendan Eich brendan at
Wed Apr 23 17:38:58 PDT 2008

On Apr 23, 2008, at 5:25 PM, Brendan Eich wrote:
> For compatibility with ES1-3, you can declare a method
> to be prototype:
>          prototype function charAt(pos)
>              string.charAt(this.toString(), pos);
> (this is from the RI), and it will be defined on the class prototype
> (String.prototype in this case, shared with string.prototype) as
> REMOVABLE, since you can do this:
> js> String.prototype.charAtfunction charAt() {    [native code]}js>
> delete String.prototype.charAttruejs>  
> String.prototype.charAt        js>

Ugh, in plain text mode dropped newlines from the paste there:

js> String.prototype.charAt
function charAt() {
     [native code]
js> delete String.prototype.charAt
js> String.prototype.charAt

> ... we would have long-winded
> (instead of ENUM, CONST, and VAR respectively). But anything so long-
> winded loses to the disjunction of flag bit constants.

I hope this is a convincing argument against naming attribute  
combinations. Bit flags or equivalent (boolean-initialized properties  
in Allen's proposal) win, because defining a property is not the same  
as declaring using special syntax, or assigning using an assignment  
expression. The "gesture" has no composite name drawn from the rest  
of the language, in a general and easy to understand way.

I don't think this is a sign of some deep flaw, although it could be  
used to argue for a larger set of narrower APIs: defineConstant,  
defineFixture, etc. -- but those would be too numerous, and  
enumerability is still mostly orthogonal to the READONLY without  
REMOVABLE vs. writable and removable or permanent combinations. So  
there'd still be an enumerable flag bit.

Still worth considering, given the unwanted two states (READONLY 
+REMOVABLE) in the table. Thanks for provoking this thread.


More information about the Es4-discuss mailing list