brett.j.andrews at gmail.com
Tue Aug 5 22:11:31 PDT 2014
My preference would be for `super()` to remain as-is, and give `super` the
equivalent semantics: reference a method of the same name in the parent
class (as opposed to invoke). I only provided the alternative since my
ultimate view is that `super` and `super()` should function similarly
(either both be legal, or both be illegal).
On Wed, Aug 6, 2014 at 2:50 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
> On Wed, Aug 6, 2014 at 12:38 AM, Rick Waldron <waldron.rick at gmail.com>
>> On Tuesday, August 5, 2014, Domenic Denicola <domenic at domenicdenicola.com>
>>> I sympathize; I have always found the fact that bare `super()` works
>>> to be confusing.
>> When a bare super() call appears in a method (whether constructor or not)
>> it can only have _one_ _meaning_ and that's a call to a method of the same
>> name in the parent class. This isn't particularly innovative:
> Note: I don't mean to imply that any of the examples I gave here are
> innovative either, they all copy the design (in a quasi-super-via-API way)
> and semantics that exist in other languages and I'd bet specifically Ruby.
> (Python requires the fully qualified name, which should be proof that JS
> has it right by allowing both forms)
>> widely used (many clones, forks and spin-offs exist) "abstract class"
>> techniques—provides `this._super()` which does the same thing that ES6
>> super() does. This pattern existed before and has been repeated throughout
>> many libraries that have stood out over the years: Prototype, Dojo, Ext.js
>> and certainly others. CoffeeScript implements super() this way as well.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss