Fwd: How much sugar do classes need?

Mark S. Miller erights at google.com
Fri Dec 5 13:15:16 PST 2008


This is the message from David-Sarah I was referring to, that uses lambda to
express a pleasant object literal, but with a leakage hazard.

---------- Forwarded message ----------
From: David-Sarah Hopwood <david.hopwood at industrial-designers.co.uk>
Date: Mon, Dec 1, 2008 at 12:01 PM
Subject: Re: How much sugar do classes need?
To: es-discuss at mozilla.org


Peter Michaux wrote:
> 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"?

It is used in E to introduce a method.

(It was also used in Logo to introduce a procedure declaration, but that
may be a coincidence.)

>> 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.

The problem is that functions are mutable, which we are stuck with for
backward compatibility. But there is no such backward compatibility
constraint on lambdas, which can and should be immutable. So, given
Allen Wirfs-Brock's syntax for lambda, we can do something like:

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

where the extensions to the object literal syntax used here are:
 - a 'field' modifier to declare a property non-[[Configurable]],
 - a 'const' modifier to declare a property non-[[Configurable]]
  and non-[[Writable]],
 - a 'method' modifier to declare a property non-[[Configurable]],
  non-[[Writable]] and non-[[Enumerable]].

Note that modifiers on object literal properties do not need to be
reserved keywords ('get' and 'set' are already in this category).

--
David-Sarah Hopwood
_______________________________________________
Es-discuss mailing list
Es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss



-- 
   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20081205/765b1e03/attachment.html>


More information about the Es-discuss mailing list