Discuss
  • usable enough private names (was: Re: Using Object Literals as Classes)

usable enough private names (was: Re: Using Object Literals as Classes)

# Herby Vojčík (14 years ago)

Domenic Denicola wrote:

Just to contribute to this... er... fun-thread...

My team uses the closure pattern for our "classes" (i.e. no prototype methods at all), since we value encapsulation. I can't imagine we're alone.

So any class solution that doesn't fully incorporate private names (e.g. by making them awkward via manual Name.create(), etc.) will leave that audience behind, still using closures and ignoring any new class sugar.

Is the current (the last winning alternative afaicr) state good enough for you?

In a few words:

private x,y;

will be desugared to

const x = Name.create(), y = Name.create();

So you would need to write your code as:

module ... { ... private foo, bar; ... class Alpha .... { ... uses names foo, bar in constructor and methods }

... maybe use the same name in subsequent classes and functions }

# Domenic Denicola (14 years ago)

Yes, this looks pretty solid, although I can't remember seeing it anywhere.

(Sorry for the top-posting; my webmail doesn't want to add the >'s for me so I figured this is better than the alternative.)

# Axel Rauschmayer (14 years ago)

private x,y; is syntactically tricky inside an object initializer. The previous consensus was to use private { x, y }

For example here: gist.github.com/1332193 (Brendan’s class proposal) gist.github.com/1336846 (my class proposal)

# Brendan Eich (14 years ago)

Axel Rauschmayer wrote:

private x,y; is syntactically tricky inside an object initializer. The previous consensus was to use private { x, y }

I don't like object literal syntax, it takes over like a weed. If classes are worth adding with higher-level (but still desugarable) semantics per yard of syntax, as I think Kevin's blog post in part argues for, then I continue to believe they'll need bespoke body-syntax -- neither object literal nor function (code).

Definitely we want sugar for

const x = Name.create(), y = Name.create();

I don't see why, given the right class body syntax, that sugar could not be

private x, y;

The old-ES4/JS2 idea of using {} for arbitrary distribution of a keyword over a list of declarators, as an alternative to C++ labeled sections, is not obviously needed. My fork of jashkenas's gist tried it out but I'm cool on it now.

# Axel Rauschmayer (14 years ago)

That makes sense.

One thing to look out for: Not loosing one’s mind due to subtle syntactic differences between modules, class declarations and object initializers (and possibly cascades). There needs to be consistency. But (implicit) rules such as “colon => separator is comma” and “equals => separator is semicolon” should make that OK.