I'm afraid that this super() discussion has gotten way off topic from the actual minimalist classes thread (which would be much more fun to talk about) -- but in the interest of dynamic class bodies, let's run it down.
On Tue, Nov 1, 2011 at 12:45 PM, Allen Wirfs-Brock <al...@wirfs-brock.com>wrote: > > Jeremy, have you looked at the current super proposal at > http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super > I hadn't looked at the current super proposal in great depth, but thanks for the link. > It does not couple super use with classes at all. It does make it easy to > define a super referencing method in an object or class literal, but the > mechanism of super can be applied to any method defined in any object. > > You are creating confusion by suggesting that the proposed ES6 super > support "fails to work at all with regular prototypes". > Browsing through the examples on the page, the current super proposal *does* seem very coupled to "classes" ... by in this case being coupled to your proposed <| operator. If you try to use the proposed super with current standard prototype patterns, this happens: Fox.prototype.dig = function() { super.dig(); }; (new Fox).dig(); TypeError: Object #<Object> has no method 'dig' Likewise, for the other usual way of setting a prototype: Fox.prototype = { dig: function() { super.dig(); } }; (new Fox).dig(); TypeError: Object #<Object> has no method 'dig' In the first case, the internal [[Super]] property is null. In the second case, the internal [[Super]] property is Object.prototype. Both cases will be quite frustrating for most JavaScript programmers. Naturally, use of the <| operator instead of ".prototype" fixes this, but that coupling of the two syntaxes was the point I was trying to make. There is also Object.defineMethod() ... which would work for setting functions-that-use-super on a prototype imperatively, but that's far too verbose of a solution to propose for the common case. All that I'm trying to say is that the super() that JS.next adopts would do well to continue to work properly in the two examples above. > Just saying "I don't think that an efficient, pay-as-you-go dynamic > super() will be easy, but with the technical chops of TC39 at your > disposal, it should be possible" is not helpful, particular when you make > other statement that suggest that you really don't understand all the > semantic subtitles of super. I hate to cite "authority" but the semantics > and implementation alternatives of super has been thoroughly explored over > 30+ years by object-oriented language designer and implementer including > myself. This is not a new problem, the "technical chops" have already been > supplied. A unique new solution that no one has ever though of before > would be welcomed. If you have such a solution, please put it forward. > But don't assume that it is something that has not already been deeperly > consider both by TC39 member and other language designers. > I hear you loud and clear, and would only be too happy to get off your lawn ;) All that I can cite is an utter lack of authority, and little experience with even undergraduate computer science -- there are very few assumptions here on my part. That said, if ES-Discuss wants to be an open forum, sometimes the rabble gets to speak up and be ignorant. So, speaking from ignorance, here's a simple proof of concept in ES3 of how dynamic super calls can work with a little bit of metadata: https://gist.github.com/1331310 ... which prints out: In the GreatGrandParent. In the GrandParent. In the Parent. In the Child. In a more ideal implementation, you'd use references to protos instead of counters, and your metadata would be scoped to be specific to an [object, methodName] pair ... but I think that this example is a bit clearer. Hopefully this solution isn't unique or new, but dynamic languages are powerful things, and I would hope that dynamic super() is a pattern that's not logically impossible or inherently inefficient to implement, given a bit of extra bookkeeping behind the scenes. Cheers, Jeremy
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
