On 26.06.2011 1:29, Axel Rauschmayer wrote:
That would be enough. I guess I’m suggesting then to implement “super” like
CoffeeScript does. Wouldn’t that be simpler?
As my next message showed, Allen's
http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super is like
CoffeScript as far as dynamic vs. lexical binding goes.
It differs in the same way that the Harmony classes proposal differs from
CoffeeScript: you call super.foo() or super.bar() from method foo. You cannot
just call super() from method foo to invoke the superclass's method foo, and
only that method.
Should we really constrain super calls in methods to be only of the same-named
method in the superclass? Conciseness is better but the restriction seems
worse. Is it necessary in Ruby or CoffeeScript?
Oh. I have never seen super used like in CoffeeScript before
JFTR: Java, Ruby, some others I'm sure (have to recall though these
"others"). It's convenient, why not? Do _you_ want to repeat every time
this _the same name_ even if you are sure that you call exactly needed,
this, method?
(which is why I haven’t even noticed it in the CoffeeScript code that I have
looked at, so far). I am strongly in favor of the more capable Harmony solution.
I guess the difference between CoffeeScript and Harmony is that CS knows the
name of the class inside a class body during compilation,
Yes, but we can write in JS this.super(...) and w/o compile time
(though, not so efficient).
Dmitry.
whereas in an object literal, you need to attach a property to a method which
points to the object. By looking at JS code generated from CS code, it seemed
that the CS approach was somehow simpler, but that was an illusion.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
