On Tue, Dec 2, 2008 at 1:54 PM, Peter Michaux <[EMAIL PROTECTED]> wrote:
> var self = {
> toString[]: {|| '<' + self.getX() + ',' + self.getY() + '>'},
> getX[]: {|| x},
> getY[]: {|| y},
> pubInstVar[WE]: 4,
> pubInstConst[E]: -4,
> };
>
> If no brackets are included then it would be equivalent to [WEC] as
> that is backwards compatible (I think).
>
> I'm not sure I like this idea. It is just an idea.
Another "just an idea":
#{ ... } is an object initializer where all of the initialized
properties are non-configurable.
'enum' (or something similar) is a property modifier that makes the
property enumerable.
'const' continues to have the same meaning (non-configurable and
non-enumerable). Where 'const' appears inside #{ ... }, the
non-configurable aspect is redundant.
var self = #{
const toString: {|| '<' + self.getX() + ',' + self.getY() + '>'},
const getX: {|| x},
const getY: {|| y},
enum pubInstVar: 4,
enum const pubInstConst: -4
};
It's more verbose than Peter's syntax, but it doesn't overload the
array index syntax, and although the #{ ... } initializer
unfortunately introduces new syntax, I think its functionality is
genuinely (and generally) useful. I'd imagine that most real-world
uses of { ... } could be replaced by #{ ... }, since initialized
properties are usually expected to stick around.
On the other hand:
enum const get foo () { ... }
... is odd.
-Jon
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
