On Tue, Dec 2, 2008 at 4:58 PM, Peter Michaux <[EMAIL PROTECTED]> wrote:
>
> I think if there are to be modifiers than just have the modifiers and
> not the #{}. Having all the modifiers with the property seems like a
> better way to go to me.
That seems fine to me, too. The #{ ... } idea just struck me, because
I realized that it pretty well captures what I actually *mean* when I
use { ... }.
> Also what if #{} is used to create the object
> and later a property is added and is to be configurable? Is that
> possible? Either decision seems arbitrary.
Yes, and I don't consider that arbitrary, at all. The meaning of
obj.foo = bar;
can't be dependent upon the mechanism used to create obj.
Now, if #{ ... } were to seal the object, then obviously you couldn't
add a new property to it. While sealed (and frozen, for that matter)
initializers would be useful in places, just enforcing
non-configurability of the initial set of properties seems like a
reasonable trade-off between general usefulness (like I said, I bet
that most uses of { ... } could be replaced by #{ ... } without a
problem) and optimizer-friendliness. (I'm thinking of Mark's number
(6) from earlier in this thread.)
Of course, there could also be initializers for sealed and frozen
objects. E.g., #s{ ... } and #f{ ... } -- or whatever. And these
would be more optimizer-friendly and less generally useful than #{ ...
}. And each would introduce new syntax. I'm in the "minimize new
syntax" camp.
>
> If there are going to be modifiers "config", "enum", and "const" then
> there may be no harm in having other modifiers which represent a
> combination of these modifiers (like the suggestions of "field" and
> "method" though I don't really like those names for the reasons I
> wrote before.)
Well, I think it's just a good practice to keep the set of modifiers
(and new syntax, in general) small.
-Jon
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
