How much sugar do classes need?

Jon Zeppieri jaz at bu.edu
Tue Dec 2 13:40:00 PST 2008


On Tue, Dec 2, 2008 at 1:54 PM, Peter Michaux <petermichaux at gmail.com> 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


More information about the Es-discuss mailing list