How much sugar do classes need?

Jon Zeppieri jaz at
Tue Dec 2 14:36:28 PST 2008

On Tue, Dec 2, 2008 at 4:58 PM, Peter Michaux <petermichaux at> 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 = 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.


More information about the Es-discuss mailing list