On Apr 23, 2008, at 4:56 PM, P T Withington wrote:
> On 2008-04-23, at 18:35 EDT, Brendan Eich wrote:
>
>> The StrawName column contains some proposed names for the
>> combinations or N/A where the combination is nonsense. These flag-
>> bit-
>> combination names do not always add clarity compared to |'ed flag-bit
>> manifest constant names, IMHO.
>
> I have to admit, those don't clarify it for me either. I'm trying to
> understand: what would I say in a class attribute declaration to get
> the corresponding properties.
The names were based, where possible, on class declaration syntax:
StrawName | READONLY ENUMERABLE REMOVABLE
------------+---------------------------------
FIXTURE | 0 0 0
PROTOTYPE | 0 0 1
VAR | 0 1 0
PROP | 0 1 1
CONST | 1 0 0
N/A | 1 0 1
ENUM | 1 1 0
N/A | 1 1 1
In ES4,
class C {
var x;
function f() ...;
}
make FIXTUREs. 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>
in ES1-3.
My choice of name for VAR is confusing since you can use var in a
class to make a fixture, but the reference is to global variables:
js> var x = 1
js> for (i in this)print(i)
x
js> delete x
false
and functions too:
js> function f(){}
js> for(i in this)print(i)
f
js> delete f
false
These are indeed not REMOVABLE, but they are ENUMERABLE, per ES1-3.
PROP is my cheesy name for a plain old ad-hoc property in ES1-3,
which is ENUMERABLE, REMOVABLE, and not READONLY. CONST is not
READONLY or REMOVABLE. ENUM is CONST with ENUMERABLE.
> If the name were mnemonic for that, it might help.
Let me know if you have better name suggestions, based on the above
(please, no EXPANDO for PROP or I'll do something dire :-/).
> If there is no way to get the corresponding properties
> with a class attribute declaration, why would we support doing so
> dynamically?
The combinations arise in different places in the existing language.
Classes define nominal types, so they are not meant to model all of
the language, in particular PROP additions to dynamic class instances
(such as good ol' Object instances) have no declarative syntax. The
object initialiser syntax is sugar, not declarative in the same sense
as class syntax -- it desugars to property "sets" or "[[Put]]" calls
to use ES1-3's meta-method, and that checks for readonly prototype
properties.
The short answer is that we have a core ES1-3 language for creating
global PROTOTYPE, VAR, and PROP attribute-sets, but users of the
language can't declare PROTOTYPE -- only the magic builtins get to
make "DontEnum" properties in ES1.3. ES4 supports FIXTURE and CONST
declarations.
I had not thought of an example of ENUM in ES4, but I believe this is
one:
obj = {const FOO: 42}.
FOO is not CONST because it should be enumerable by for (i in obj)
constructs.
ES4 purists might object that the FOO initialiser makes a fixture,
but not a FIXTURE -- but if the game here is to name all sane
attribute bit combinations, then it's hard to win with short names
and avoid dropping FIXTURE from all the fixture variants. So I went
with ENUM, and that name could be expanded to ENUMERABLE_CONST where
CONST implies "fixture". So 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.
/be
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
