On Thursday, May 24, 2012 at 5:36 PM, Russell Leggett wrote:
> On Thu, May 24, 2012 at 4:50 PM, Erik Arvidsson <[email protected]
> (mailto:[email protected])> wrote:
> > [snip]
> >
> > The problems with these is that no other dynamic language has these
> > kind of requirements. JS developers get by without them today. If we
> > designed a new language I think they would be nice features to have
> > (ahem Dart) but our goal is to improve ECMAScript and not replace it.
> > We should not try to make all languages fit into the same box.
> >
> > At this point I think it is up to Waldemar and supporters of his
> > requirements to come up with concrete proposals how these things can
> > fit into ECMAScript. (Thanks Russel for starting this thread.)
>
> Yes, I would really like to see some more elaboration from him. I guess we'll
> have to wait for his return. One of the things that I was trying to show was
> that the max/min proposal is not future hostile, whether or not these things
> happen now, especially if it is not the default. I really just don't want
> classes to be blocked.
Agreed 100%, especially considering the favorable consensus appears to be in
the majority now.
I may be in left field here, but what stops:
class C {
f = "foo";
constructor() {
}
}
From desugaring to:
function C() {}
C.prototype.f = "foo";
I looked through as many of the class related proposals and couldn't find
anything that disproved this possibility
Rick
>
> - Russ
>
> >
> > On Thu, May 24, 2012 at 1:27 PM, Axel Rauschmayer <[email protected]
> > (mailto:[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.
> > >
> > > 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.
> > >
> > >> - 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,
> > > 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]]).
> > >
> > >> - 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()?
> > >
> > > --
> > > Dr. Axel Rauschmayer
> > > [email protected] (mailto:[email protected])
> > >
> > > home: rauschma.de (http://rauschma.de)
> > > twitter: twitter.com/rauschma (http://twitter.com/rauschma)
> > > blog: 2ality.com (http://2ality.com)
> > >
> > >
> > > _______________________________________________
> > > es-discuss mailing list
> > > [email protected] (mailto:[email protected])
> > > https://mail.mozilla.org/listinfo/es-discuss
> > >
> >
> >
> >
> > --
> > erik
>
> _______________________________________________
> 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
