Question about constructor property vs. instanceof
in [JavaScript]
|
Prev: How to link CSS(s) already linked to parent frame into child iframe using javascript
Next: Error getElementbyClassName
From: Garrett Smith on 17 Jan 2010 19:26 Asen Bozhilov wrote: > Dmitry A. Soshnikov wrote: > >> * No optimization; >> * No whatever; >> * scope chain of wrapped methods and wrapper will have some garbage; >> * I *don't* use this pattern (and have never used) in production, this >> is *just academical interest*; >> * I don't like this pattern, it's just to show alternative. > > Why not use full power of the language? You can use the full power of > the Prototype Chain. See example: > > Object.prototype._super = function(name) > { Create a `_super` property for all objects? What for? Do you really want that to show up in for-in loops? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Asen Bozhilov on 18 Jan 2010 05:03 Garrett Smith wrote: > Create a `_super` property for all objects? What for? Do you really want > that to show up in for-in loops? Definitely NO. That is only example. With adding `_super' to all objects permit me, to concentrate over a algorithm. In production code, definitely I'm not use `_super' in this way. Regards.
From: Jorge on 18 Jan 2010 05:41 On Jan 17, 7:05 pm, Jorge <jo...(a)jorgechamorro.com> wrote: > > Object.prototype.hasOwnProperty.call({ hasOwnProperty: null }, > "hasOwnProperty"); > --> true ({}).hasOwnProperty.call({hasOwnProperty:null},"hasOwnProperty"); --> true -- Jorge.
From: kangax on 18 Jan 2010 12:16 On 1/17/10 12:55 PM, Thomas 'PointedEars' Lahn wrote: > kangax wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> kangax wrote: >>>> Asen Bozhilov wrote: >> [...] >>>>> }, >>>>> >>>>> addProperties : function(o) >>>>> { >>>>> for (var i in o) >>>>> { >>>>> if (o.hasOwnProperty(i)) >>>> >>>> Would be safer to do: >>>> >>>> if (Object.prototype.hasOwnProperty.call(o, i)) >>> >>> How so? All built-in objects need to implement hasOwnProperty() as they >>> have Object.prototype in their prototype chain, and nobody sane would >>> pass a host object here. >> >> Think about what happens when `{ hasOwnProperty: null }` is passed to >> `addProperties` method. > > Nobody sane would create such an object either, or pass a reference to it > to this method. "Nobody sane ..." is a weak argument. It's also not the most robust approach to designing software. I'm surprised to hear this kind of reasoning from *you*. And think wider. What if an object (to be iterated over) has `hasOwnProperty` that references Function object other than what `Object.prototype.hasOwnProperty` originally references. Instead, it's a Function object that is to become an instance method: .... addProperties({ hasOwnProperty: function(){ /* my instance method */ } }) .... If that's too improbable for you, let your program fail (or have unexpected behavior). I'll use trivial workaround instead. [...] -- kangax
From: Thomas 'PointedEars' Lahn on 19 Jan 2010 07:33
kangax wrote: > Thomas 'PointedEars' Lahn wrote: >> kangax wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> kangax wrote: >>>>> Asen Bozhilov wrote: >>> [...] >>>>>> }, >>>>>> >>>>>> addProperties : function(o) >>>>>> { >>>>>> for (var i in o) >>>>>> { >>>>>> if (o.hasOwnProperty(i)) >>>>> >>>>> Would be safer to do: >>>>> >>>>> if (Object.prototype.hasOwnProperty.call(o, i)) >>>> >>>> How so? All built-in objects need to implement hasOwnProperty() as >>>> they have Object.prototype in their prototype chain, and nobody sane >>>> would pass a host object here. >>> >>> Think about what happens when `{ hasOwnProperty: null }` is passed to >>> `addProperties` method. >> >> Nobody sane would create such an object either, or pass a reference to >> it to this method. > > "Nobody sane ..." is a weak argument. It's also not the most robust > approach to designing software. I'm surprised to hear this kind of > reasoning from *you*. Nonsense. You cannot deal with every possible situation. Most importantly, it is not your place as a library author to second-guess the caller's intention. > And think wider. What if an object (to be iterated over) has > `hasOwnProperty` that references Function object other than what > `Object.prototype.hasOwnProperty` originally references. I am well aware of that. However, in a nutshell, I simply do not subscribe to that idea of yours, common these days, of the stupid library user. If what you describe was the case, due to lack of evidence to the contrary we must assume that it was the intention of the caller of the method to work that way, their being aware of all the consequences of such a design decision. If it was not their intention, then quality assurance at the caller's would be supposed to show that it is not practical to call our method passing a reference to that object; which, since it would work with references to other objects, must be attributed by a reasonable caller to them doing something wrong. In fact, if we would call Object.prototype.hasOwnProperty() on their object and the intention of the caller was to have their own hasOwnProperty() implementation applied instead (so that certain properties are considered for for-in iteration and others are not), we would ignore their explicit wishes, which would make our library less an attractive way for them to do what they want to do. Our documentation should provide information as to what we are doing, so that users of our library are aware of it, but that should be the end of it. And if you consider the abomination that especially jQuery has grown into, heavily overloading $() (or jQuery()) so that it could (possibly) deal with every possible argument, which has created the need to work around the quirks of every previously unknown implementation in the process (and deprecate those implementations which this approach is incapable to deal with), you can see that what I describe above is the only logical course of action for a library author. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004) |