Minimalist Classes

Jeremy Ashkenas jashkenas at gmail.com
Tue Nov 1 11:04:24 PDT 2011


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 <allen at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111101/e77d4080/attachment.html>


More information about the es-discuss mailing list