On 03/29/2012 08:30 PM, Allen Wirfs-Brock wrote:
I don't think the report on maximally minimal classes fully reflections the
discussion:
Maximally minimal classes:
Alex and Allen initiated the discussion as a status up-date to TC-39.. We
pointed out that this proposal had recently been extensively discussed on
es-discuss and that it appear to have considerable support from most of the
participants in that discussion.
Luke: These aren't good enough to be a net win.
I'm not sure whether this is an exact quote.
It is.
Luke certainly did raise the issue of whether classes, as defined by this
proposal, added enough functionality to ES to justify the inherent complexity
of a new feature.
Allen and Alex reiterated that this proposal is only trying to address the most
common class definition use cases but in a way that allows for future
extensions to address a broader range of use cases. These is significant value
in what the proposal provides even if it doesn't do everything any might want.
dherman stated he has some minor design issues he wants to further discuss, but
that overall the level of functionality in this proposal was useful and would
be a positive addition. He supports it.
Waldemar: These don't address the hard problems we need to solve.
Concerned about both future-hostility (making it cumbersome for future
classes to declare, say, object layout without cumbersome syntax by
taking over, say, const syntax) and putting developers into a quandry
We discussed this concern quite a bit and did not identify any specify ways in which the
current proposal would block future extensions. Waldemar was asked to provide specific
examples if he comes up with any. Allen pointed out that future syntactic additions can
also enforce new semantics. For example addition of a per instance state declarations
and a "const" keyword to the constructor declaration could cause ad hoc
this.property assignments to be statically rejected, if that was a desired semantics.
-- if they want to do anything more sophisticated, they'll need to
refactor their code base away from these classes. Unless one choice
is clearly superior, having two choices (traditional and extended
object literals) is better than having three (traditional, extended
object literals, and minimal classes). Minimal classes currently
don't carry their weight over extended object literals. Perhaps they
can evolve into something that carries its weight, but it would be
more than just bikeshedding.
The above is a statement of Waldemar's opinion. Other opinions expressed in the
discussion aren't record in the original notes.
Yes, I marked it as such. Most of the other opinions had already been
eloquently expressed on es-discuss.
Alex: We need to do something.
Allen and Alex also expressed that it is unlikely that any class proposal that
significantly goes beyond will be accepted for ES6.
I don't remember that. Probably just missed it, but there wasn't much
discussion of that option.
Debated without resolution.
In summary:
Waldemar should identify any specific ways that the syntax or semantics of this
proposal would be future hostile.
Waldemar, Luke, and MarkM expressed varying levels of concern as to whether the
user benefit of the proposal was sufficient to justify its inclusion. In order
to resolve this question, both sides of the issue really need to provide better
supporting evidence for the next meeting.
Allen
Thank you for the corrections. It's sometimes hard for me to participate and
take notes at the same time, and I welcome corrections.
Waldemar
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
