On Thu, May 24, 2012 at 4:27 PM, Axel Rauschmayer <[email protected]> wrote:
> - One key question: Does a property declaration have to look declarative
>> in order to be used declaratively? You are saying no.
>>
>
> I think a more declarative form could be added later, this is not future
> hostile to that.
>
>
> It looks OK to me. However, adding another form later seems like a bad
> idea.
>
An immediate example would be something like adding private properties.
class Point(){
private x;
private y;
constructor(x,y){
@x = x;
@y = y;
}
}
In this case, the keyword private might create a private name, as well as
declare the property exists on the instance. The constructor would simply
set the value. This is something which could work in either a const, or
non-const class. I'm not proposing this now, just saying its a possibility.
> What is currently here makes it so that any properties added during
> construction are non-configurable. Assuming the constructor gets run, and
> assuming properties are not added conditionally, guarantees can be made.
>
>
> Wouldn’t the instance be frozen? Then all properties would be
> non-configurable and non-writeable and the instance would not be extensible.
>
The instance itself would be sealed. The prototype would be frozen, though.
So basically, data would be writable, but methods would not. Because
non-method properties cannot be put on const classes, this makes a pretty
strong guarantee about the separation between data and behavior.
> - One could have `public foo = ...` as syntactic sugar for `this.foo =
>> ...`. But then the issue is whether `private` will ever be used in an
>> analogous manner (my understanding: no).
>>
>
> Going with the max/min approach of tiny additions. The only addition here
> is the const keyword in front of class. Big bang for the buck.
>
>
> I agree.
>
> - Subtyping is going to be a bit tricky, because a constructor has to
>> behave differently if called from a subconstructor.
>>
>
> This is covered in the original proposal, and I would have it work the
> same:
> "During construction of an instance of a const class, the instance is
> extensible. Each public declaration adds a non-configurable, (possibly
> non-writable) data property to the instance. During constructor
> chaining<http://wiki.ecmascript.org/doku.php?id=harmony:classes#constructor_chaining>,
> the [[Call]] method of the superclass constructor, even if const, does not
> make the instance non-extensible. Rather, the [[Construct]] method of a
> const class makes the instance non-extensible before returning. An instance
> of a non-const class which inherits from a const class is thereby born
> extensible unless the constructor makes it non-extensible by other means.
> Taken together, instantiating a const class must result either in a thrown
> exception, non-termination, or in an instance of that class with the public
> own properties declared within the constructor of that class."
>
>
> Nice. But it goes beyond a class declaration being syntactic sugar for a
> function (unless one introduces a way to specify [[Construct]]).
>
Yes, other than the syntax, I suppose this is the biggest addition. I think
it makes sense, though, and thats pretty out of the way from users.
>
> - I would love to have sealed instances. Those would be great for catching
>> typos and performing shape-related optimizations.
>>
>
> Yes, I think I might have specified this poorly. I'm seeking the same
> behavior as the original const class proposal. Instances would be
> non-extensible upon completion of construction. Nothing could be added or
> removed. Methods would be non-writable, but data would be. As I indicated,
> private names can be used to protect against unwanted mutation.
>
>
> What function (or equivalent operation) would [[Construct]] apply to an
> instance after initialization? Object.seal() or Object.freeze()?
>
Object.seal()
-Russ
>
> --
> Dr. Axel Rauschmayer
> [email protected]
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
