On May 30, 2012, at 4:42 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> On May 30, 2012, at 4:15 PM, Brendan Eich wrote: >> >>> At last week's meeting we deferred super outside of class methods. >> >> We talked about it, but I don't see the above statement captured in the >> minutes. > > From Rick's notes of day 2: > > > AWB: > - Asserts that super is defined correctly for classes > (explanation) > > Should super be allowed in all function forms or restricted to classes? > > Resolution: Defer super outside of classes
oops, I searched the next message where you had added some additions to Rick's notes. I didn't notice that it wasn't a complete quote of the original message... > > > See https://mail.mozilla.org/pipermail/es-discuss/2012-May/022838.html > >> It also isn't clear what you mean by "deferred". > > One precedent: > > http://wiki.ecmascript.org/doku.php?id=strawman:deferred > > We sometimes kill things outright too. > > What we agreed to last week: no |super| outside of classes in ES6, no > Object.defineMethod in ES6. That's what I recall and what the notes say (re: > |super|). I also don't see the mention of defineMethod although I know we talked about it. I agree that we have a deferral of super/defineMethod but I personally don't think the former is going to stay deferred, if we reach agreement on classes that have super. Ultimately, I think we will find that we can't have a semantics like |super| that is only usable within a syntactic class definition but has no reflective support and no way way to programmatically desugar a class definition into the exact equivalent set of object definitions. That's only half a solution. support of |super| outside of class is the only think missing to enable that. So, it something I will likely continue top push on. In that light mustache with super containing concise methods seems like a very good way to avoid the defineMethod usability issues. > ... >> Also, last week there was support for .( expressed both from the perspective >> of the Smalltalk-like cascaded expression use cases and from the >> definitional object extension perspective. > > Those are two different use-cases, operational semantics, and (therefore) > syntaxes, though -- this thread makes that pretty clear. > >> My perception is that different people were had primary interests in the >> different use cases. Just because we may be on the path of a solution to >> the cascaded expression use cases doesn't mean there isn't still interest >> and support for the definitional use cases. > > Who said there isn't "interest"? We're trying to keep what's in ES6 > consistent, which is why I used "deferred". I'd be happy deferring beyond > strawman at this point. We need to button down ES6. Here is what I see. At the meeting, we decide to look at a "mustache" that addressed two generally orthogonal sets of use cases. We looked at that and found significant issues in using one construct for both sets of use cases. We then saw how we could use distinct syntax for the two sets of use cases and avoid those issues. However, at that point some of us, who seem primarily interest in only one of the use case sets seem to be essentially saying (just my perception), ok I have may solution, let's blow off the other set of use cases as they aren't very important. I think this is all moving a bit too fast. there are a lot of good ideas over the last couple days and we need to be careful to start playing wack-a-mole with them. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
