How much sugar do classes need?

Brendan Eich brendan at
Sun Nov 30 15:53:16 PST 2008

On Nov 30, 2008, at 1:11 PM, Peter Michaux wrote:

> On Sat, Nov 29, 2008 at 9:49 PM, Mark S. Miller <erights at>  
> 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"?

IIRC, Mark's E language used that preposition. Think "in order to..."  
before the verb-phrase-named function.

It may grow on you -- I see its intent, but observe that others such  
as Peter miss it because "to" is an overloaded term in English and in  
JS (to toString shows two among the plurality of meanings).

What's more, 'to' seems unnecessary in JS object initialisers, given  
the unambiguous property name syntax. Instead of : after the property  
name (which could be an identifier, number, or string), a ( begins a  
formal parameter list.

ES4 allowed const and var before the property initialiser, to specify  
DontDelete and optionally ReadOnly, as opposed to neither for the  
property initialisers in ES3. In this light, var is better than let.

Using let before a property name in an object initialiser might  
plausibly create a "lexical" member of the new object, whatever that  
could be. It wouldn't be a property of the kind defined by var or  
const. But without an implicit closure I don't see how to do this, and  


More information about the Es-discuss mailing list