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 <[email protected]>
To: Mark S. Miller <[email protected]>
Cc: es-discuss <[email protected]>
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 <[email protected]> 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
>>
>>[email protected]
>>twitter.com/rauschma
>>
>>home: rauschma.de
>>blog: 2ality.com
>>
>>
>>
>>_______________________________________________
>>es-discuss mailing list
>>[email protected]
>>https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
>--
> Cheers,
> --MarkM
>
--
Dr. Axel Rauschmayer
[email protected]
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
