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 <[EMAIL PROTECTED]> Date: Mon, Dec 1, 2008 at 12:01 PM Subject: Re: How much sugar do classes need? To: [email protected] Peter Michaux wrote: > On Sat, Nov 29, 2008 at 9:49 PM, Mark S. Miller <[EMAIL PROTECTED]> 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM
_______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
