March 29 meeting notes
waldemar at google.com
Fri Mar 30 15:50:49 PDT 2012
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.
> 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.
Thank you for the corrections. It's sometimes hard for me to participate and take notes at the same time, and I welcome corrections.
More information about the es-discuss