How much sugar do classes need?

Peter Michaux petermichaux at gmail.com
Sun Nov 30 13:11:40 PST 2008


On Sat, Nov 29, 2008 at 9:49 PM, Mark S. Miller <erights at google.com> wrote:

>>  var self = {
>>    to toString() {
>>      return '<' + self.getX() + ',' + self.getY() + '>';
>>    },
>>    to getX() { return x; },
>>    to getY() { return y; }
>>    let pubInstVar: 4,
>>    const pubInstConst: -4
>>  };
>>  return self;

> The "to" isn't a typo, but wasn't explained. It creates a non-writable,
> non-enumerable, non-configurable property whose value is a frozen function.

What is the motivation for choosing the string "to"?

> I am not attached to the specifics of my "object"/"public" block. But what
> this thread has already taught me is that it is instances that need sugar,
> not classes. Enhancing the object literal notation is one way to get there.

The object literal notation shouldn't be burdened with freezing the
actual function object. The object literal should at most allow
specifying that it's own property reference is frozen. The object
literal freezing the function object itself seems like going a step to
far. For example, what if the property value is an object with yet
another object nested inside? Would the top object literal allow
freezing of the whole deep structure? That seems uncomfortable to me.

Peter


More information about the Es-discuss mailing list