Class literals: does "public" still make sense?

[Brendan Eich]

On Sep 24, 2011, at 7:09 PM, Mark S. Miller wrote:

> However, when used as the only or main means of initializing an instance, it defeats one of the main purpose of classes: The shape of the instances of a given class are no longer a static declarative feature of the class itself.

Hi Mark, a minor nit-pick: static meaning for all time from construction on applies only for 'const class'. For just 'class', there's no such shape guarantee.


> Again, the contrast with modules is instructive. A CommonJS module exports only by imperative assignment to properties of an "exports" object. A proposed ES-next module exports by annotating top level declarations with "export".

Modules are not objects unless you ask for their reflections, and the reflecting module object is sealed. This is in contrast to non-const classes, the nit-pick again.


> As an abstraction mechanism, it would be bizarre to have good abstraction properties only for abstractions that cannot be multiply instantiated.

Modules are instantiated in a real loaded-by-module-loader sense, but not observably as objects unless you ask for a reflection. The reflection must be sealed or the early errors for misspelled/mismatched import vs. export usage are lost, or become prone to confusion (e.g. if we allowed dynami expandos on module objects but they of course did not inject dynamic bindings into the module's scope).

These differences seem more than nits. If you have a const class, you have a factory (itself hardened by freezing) that creates sealed instances. A module is not a factory at all, and its memoized reflection is sealed.

Having written all this, I agree we want declarative syntax for class instance variables.

/be


> 
> 
> On Sat, Sep 24, 2011 at 4:17 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
> Without private members, do we still need the keyword "public" in class literals?
> 
> For example, instead of
>  constructor(geometry, materials) {
>    super(geometry, materials);
> 
>    public identityMatrix = new THREE.Matrix4();
>    public bones = [];
>    public boneMatrices = [];
>    ...
>  }
> I find the following just as intuitive, without the need for the keyword "public":
>  constructor(geometry, materials) {
>    super(geometry, materials);
> 
>    this.identityMatrix = new THREE.Matrix4();
>    this.bones = [];
>    this.boneMatrices = [];
>    ...
>  }
> 
> Similarly intuitive is something that I’ve seen somewhere – passing through constructor arguments as members.
>  class Point {
>    constructor(this.x, this.y) {
>    }
>  }
> 
> I don’t think "public" helps, I think it makes things *less* intuitive.
> 
> --
> Dr. Axel Rauschmayer
> 
> axel at rauschma.de
> twitter.com/rauschma
> 
> home: rauschma.de
> blog: 2ality.com
> 
> 
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> 
> 
> 
> -- 
>     Cheers,
>     --MarkM
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110925/58ed8d5d/attachment.html>