Class literals: does "public" still make sense?

[Kam Kasravi]

If the intent of classes is to provide a declarative syntax for its 'shape' then dropping the private syntax in lieu of private name objects seems to run counter to this philosophy. 
As I understand it, private name objects are a runtime construct dependent on the '@name' module and thus have no declarative definition. 
Are there yet to be defined ways to declaratively define/discover an instances private namespace?



________________________________
From: Axel Rauschmayer <axel at rauschma.de>
To: Mark S. Miller <erights at google.com>
Cc: es-discuss <es-discuss at mozilla.org>
Sent: Sunday, September 25, 2011 8:59 AM
Subject: Re: Class literals: does "public" still make sense?


Static analysis of the constructor should be able to do most of what "public" does, but after consulting the spec again, I see its advantages:
- Const classes make public properties unconfigurable and read-only.
- Shouldn’t public properties in non-const classes be unconfigurable, too? Are such properties expected to be configured? Read-only properties could be created via "public const".

On Sep 25, 2011, at 4:09 , Mark S. Miller wrote:

Hi Axel,
>
>
>This was one of the options we considered. At one point it was the main class proposal. The problem is that since it looks exactly like an imperative assignment to a property of "this", it should have the semantics of an imperative assignment to a property of "this". In fact, the current class proposal does not disallow it, and gives it exactly these semantics.
>
>
>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. 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". As an abstraction mechanism, it would be bizarre to have good abstraction properties only for abstractions that cannot be multiply instantiated.
>
>
>
>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
>

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110925/409a6fd6/attachment-0001.html>