Prev: How to link CSS(s) already linked to parent frame into child iframe using javascript
Next: Error getElementbyClassName
From: Yoda on 13 Jan 2010 07:37 On Jan 13, 1:22 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > Delete the whole damned thing. Please. Who said it was elegant ? -- Jorge.
From: Thomas 'PointedEars' Lahn on 13 Jan 2010 07:40 Jorge wrote: > Jorge wrote: >> Thomas 'PointedEars' Lahn wrote: >> > (...) >> > o.foo = function() { >> > /* >> > * Pray call C.prototype.foo() here without referring >> > * to the constructor or the prototype object >> > */ >> >> //Pay close attention, Pointy: >> >> var save= this.foo; >> delete this.foo(); >> this.foo(); >> this.foo= save; > > s/delete this.foo()/delete this.foo; It is a possibility, although it remains to be seen whether it is more efficient than simply calling the prototype's method. Given the possibility of setters and getters, it is certainly more error-prone than the direct approach already. Anyhow, now try that in a prototype method -- it will not work, because `this' refers to the calling object, not its prototype. And if you are still not convinced that this approach is not a general good solution, pray call the foo() method of the second-next object in the prototype chain now (again, without referring to prototype objects or constructors, per your claim.) PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Jorge on 13 Jan 2010 07:51 On Jan 13, 1:40 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > (...) > Anyhow, now try that in a prototype method -- it will not work, because > `this' refers to the calling object, not its prototype. And if you are > still not convinced that this approach is not a general good solution, pray > call the foo() method of the second-next object in the prototype chain now > (again, without referring to prototype objects or constructors, per your > claim.) Sorry, as for today, I've run out of tricks. -- Jorge.
From: David Mark on 13 Jan 2010 08:09 Thomas 'PointedEars' Lahn wrote: > Jorge wrote: > >> Jorge wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> (...) >>>> o.foo = function() { >>>> /* >>>> * Pray call C.prototype.foo() here without referring >>>> * to the constructor or the prototype object >>>> */ >>> //Pay close attention, Pointy: >>> >>> var save= this.foo; >>> delete this.foo(); >>> this.foo(); >>> this.foo= save; >> s/delete this.foo()/delete this.foo; > > It is a possibility, although it remains to be seen whether it is more > efficient than simply calling the prototype's method.] Certainly it is not as efficient. A call plus a delete, plus a couple of assignments and an extra variable? No way that's faster than a call (even with one extra dot operation). ;) > Given the > possibility of setters and getters, it is certainly more error-prone than > the direct approach already. It's just a God-awful example. I'm sure Crockford doesn't advocate actually using it. I don't even think Jorge is that crazy. > > Anyhow, now try that in a prototype method -- it will not work, because > `this' refers to the calling object, not its prototype. Yes, you would have to do the switcheroo on the prototype in that case. I thought that was the variation he was going to post. Certainly neither is a Good Part. :)
From: Dmitry A. Soshnikov on 13 Jan 2010 08:16
On Jan 13, 3:05 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Yes, it has. "In computer science, polymorphism is a programming language > feature that allows values of different data types to be handled using a > uniform interface. [...]" (en.Wikipedia) > Polymorphism regarding to ECMAScript is related to several things. And about polymorphism - ECMAScript is polymorphic in several meanings: 1. e.g. function could be applied to some objects as it's own method of that objects: function test() { alert([this.a, this.b]); } test.call({a: 10, b: 20}); // 10, 20 test.call({a: 100, b: 200}); // 100, 200 var a = 1; var b = 2; test(); // 1, 2 Or, so called, *parametric polymorphism*, when function is one for all types, but accepts mutable functional argument (Funarg). As example: `sort method of arrays - it accepts sort-function, but `sort' method itself - is common (one interface (.sort-method), several implementations (sort-functions) - polymorphism, and `sort' method is polymorphic). Or, regarding to duck (weak) typing (DT), - DT - is also kind of polymorphism, as it's doesn't matter *what type* is object, but important whether it able to handle some activity. Again - common one interface of an object is essential, and there can be several implementations of it - again polymorphism. So, it's not only about method overloading. > > You don't know what you are talking about, or you are unable to read and > understand English. Probably both. > Demagogy. > > Idiot. > Would you mind if I suggest to filter your words before posting? > /* JScript .NET has `super' to refer to the superclass */ > super.foo(); By the way, there's also one more ability to call overwritten parent method just with `this._super()' expression. One (old) I've already shown and it's well-know - to make special wrappers for that (by the performance it's less efficient then using `constructor.superclass', but from the elegant code - is). But the second one - is not so widespread - is using `caller' property. Sure, this is dangerous (especially for ES5) but as variant - in your own project - it's a good alternative. /ds |