An experiment using an object literal based class definition pattern

Brendan Eich brendan at mozilla.com
Fri Aug 5 07:46:09 PDT 2011


On Aug 4, 2011, at 11:00 PM, Allen Wirfs-Brock wrote:

> On Aug 4, 2011, at 8:39 PM, Axel Rauschmayer wrote:
> 
>>> Another idea was an alternative way to express the "extend" operator for literal property definitions.  Doug Crockford suggested the following syntax:
>>> 
>>>     obj.{
>>>        prop:1,
>>>        prop:2
>>>        }
>> 
>> It looks nice, but the operator should also work for a RHS that is not an object literal.
> 
> But using . as the operator it would be ambiguous with normal property access.  A different and unique operator wouldn't have the problem but also wouldn't look so nice and the primary motivation for the operator is for use in expression such this post is about.

Still, unliked <|, an extend function (built-in module export) would be useful in more cases, based on Prototype and other libraries' Object.extend.


>  An alternative that could work would be to allow a parenthesized expression to follow the dot.

ECMA-357 (E4X) uses that for something we want to get rid of (filtering predicates, 'with' like things). So a.(b) as Object.extend(a, b) is possible, but again there is not strong need for an operator.

Using a.{p1:v1,...} syntax is attractive in its own right, but not as a final syntax in lieu of classes.


>> How about rewriting this as follows?
> I did something similar in my first go at this, but there is a problem...

Right, the desugaring from class syntax is fragile and error-prone. It's clever, but it doesn't eliminate the higher-level win of consolidated class syntax -- provided we can agree on class-method sections, class-side inheritance, and the other open issues.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110805/4c96010a/attachment.html>


More information about the es-discuss mailing list