On Sep 25, 2011, at 1:04 PM, Kam Kasravi wrote: > 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.
We did not agree to drop the private declaration syntax at the July TC39 meeting. Perhaps my understanding of our agreement then does not match Marks? What we agreed to drop was the private(this) straw syntax in the classes proposal, in favor of this[x], this[y], for private-declared private name objects x and y. /be > 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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
