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, Mail.app in plain text mode dropped newlines from the paste there:
js> String.prototype.charAt
function charAt() {
[native code]
}
js> delete String.prototype.charAt
true
js> String.prototype.charAt
js>
> ... we would have long-winded
> ENUMERABLE_CONST_FIXTURE, CONST_FIXTURE, GLOBAL_VAR, etc. names
> (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.
/be
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
