So you are asking how "super" works with generic methods? Good question.
Statically, things are easy: super.describe() at (*) will always invoke
oddball.describe()
Dynamically, things are tricky. call() would have to use the "here" of
object.describe which is object. Thus, super.describe() would find
oddball.describe and give it a "this" === Object.create(another).
I’m not sure "super" makes much sense in generic methods, because those stand
largely on their own.
On Oct 4, 2011, at 2:15 , Quildreen Motta wrote:
> On 03/10/11 20:44, Axel Rauschmayer wrote:
>> super being rare and moving methods being rarer, I think the tradeoff for
>> performance is OK, especially as there will be a method that allows you to
>> move methods. If performance wasn’t an issue, dynamic "super" would be
>> preferable.
> Hm, I wouldn't consider moving methods to be that rare, unless you're taking
> into account only people coding in a declarative style. In that case, moving
> a method would be a weird thing to do. On the other hand, if you're writing
> imperative prototypical code, moving methods might not be such a rare thing —
> more so if we take into account the lack of multiple-inheritance facilities
> in JS, which would lead someone to use things like mixins (thus, more
> overhead due to manual copying, but mixins are — or should be — parentless
> anyways).
>
> Note, though, that this is based only on my own code. I am not much
> knowledgeable about the general use-case of JavaScript, so feel free to
> correct me where I'm rambling non-senses :3
>
> Another point is what "here" should refer to in a situation like:
>
> ---
> var oddball = {
> clone: function() {
> this.instances = (+this.instances || 0) + 1
> return this }
> , describe: function() {
> return this.name + ' has ' + this.instances + ' copies' }}
>
> var object = oddball <| {
> describe: function() {
> return '<#object ' + super.describe() + '>' }} // (*)
>
> var me = object.clone()
> me.name = 'Me'
>
> var another = {
> describe: function() {
> return 'The princess is in another castle.' }}
>
> me.describe()
> // => '<#object Me has 1 copies>'
>
> object.describe.call(Object.create(another))
> // => '<#object undefined has undefined copies>'
> ---
>
> In this case, should `here' take into account the object in which the action
> `describe' is defined, in this case resolving to `oddball.describe', or
> should it take into account the object that was the target of the action, in
> this case resolving to `another.describe'.
>
> My opinion is that the latter makes more sense, but that's because I see
> `thisObject' not just as a data-container, but something that describes the
> full behaviours of a thing.
>
--
Dr. Axel Rauschmayer
[email protected]
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
