Prev: how to get url of script
Next: question of logic?
From: Andrea Giammarchi on 20 Mar 2010 15:20 On Mar 20, 11:49 am, David Mark <dmark.cins...(a)gmail.com> wrote: > Michael Haufe ("TNO") wrote: > Ignorance with a generous helping of incompetence. It started out okay, > but went off the rails on the second line. the fact the library is not updated with a clear link to the latest version marked 2007/11/03 and released actually 2 or 3 years after that one posted just to provide some old trick able to bring JS features in IE4 does not tell you anything, right? What about being simply superficial and arrogant? Do you write code like that? Can't wait to blame your first script ... uh wait, if it was you, I am sure it is perfect, right? Ridiculous. Anyway, this happens when you would like to share or help, and people are ready to show off remarking silly things without investigating a little bit (e.g. with the updated version) for a death project like that, as death is IE4, still there for case studies like those Thomas is doing with code that should be compatible with IE4. @Thomas, I do believe you lack of sarcasm (C=64), while I have never read a single valid point about your constructor check. I think you will be the only one in this world to use such deprecated and wrong check which is also against JS prototypal inheritance concept, where functions, as constructors, are simply implicit initializers and nothing else, able to chain the current prototype, and again nothing else. In JS objects extend objects, but I am sure you know that instanceof simply checks it, as sure I am that you will use instanceof for every browser, except those nobody uses anymore such IE4 ... isn't it? I would like to know how you trap in closure try catches and how you use them, since IE4 will throw an error as soon as you call those methods ... should we talk about sniffing? or you have better options to know if the browser is IE4 ? And what about the code size, is it a dedicated IE4 version against the rest of the real world or what? Finally, I will learn to quote, but too often this ML is just a show off place with zero outcome and few valid points ... I do hope this ml will grow up some day, so far I have read too often just "blame for free to become famous" behaviors, annoying for both seniors and juniors, useless for the community. Best Regards
From: Andrea Giammarchi on 20 Mar 2010 15:28 On Mar 20, 1:43 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote: > Thomas 'PointedEars' Lahn wrote: > > Andrea Giammarchi wrote: > > > So, how can you get confuse about that variable called __proto__? > > > (It is a function _argument_, not a variable.) How can you be naming an > > function argument like that? > > It can be harmful. Not only confused readers, but can pollute Scope > Chain in strict implementation of ECMA-262-3. If `__proto__` is mimic > of [[Prototype]] property, that can change Prototype Chain of VO. And > during Identifier Resolution will be lookup in Prototype Chain of next > object in Scope Chain. So in theory that property name of VO is > harmful: > > var x = true; > (function () { > var __proto__ = {x : false}; > > print(x); //? > > })(); > > I can't see any implementation there print "false", but in theory can. > So it's depend by implementation of AO/VO and definitely i can't use > Identifiers like this. > > 1. Confuse readers > 2. In some implementations can pollute Scope Chain. Of course that > point is only in theory. dude, I do believe you are looking for this: var x = true; with({}){ (function () { __proto__ = {x : false}; alert(x); }()); } which as you know, is different from this: var x = true; with({}){ (function (__proto__) { alert(x); }({x : false})); } however, I will never use that function as it was written, it was a proof of concept, and nothing else, I am fine with instanceof operator, I don't care about Commodore 64 ;-)
From: David Mark on 20 Mar 2010 15:39 Andrea Giammarchi wrote: > On Mar 20, 11:49 am, David Mark <dmark.cins...(a)gmail.com> wrote: >> Michael Haufe ("TNO") wrote: >> Ignorance with a generous helping of incompetence. It started out okay, >> but went off the rails on the second line. Er, that's my line (not Michael's). > > the fact the library is not updated with a clear link to the latest > version marked 2007/11/03 and released actually 2 or 3 years after > that one posted just to provide some old trick able to bring JS > features in IE4 does not tell you anything, right? I was commenting on the code presented. As I said, I hoped it was very old. If it was from 2004 (if I get your meaning), that is unfortunate. > > What about being simply superficial and arrogant? I don't care for it. Not a bit. :) > Do you write code > like that? Not for almost a decade. > Can't wait to blame your first script ... uh wait, if it > was you, I am sure it is perfect, right? Ridiculous. I didn't say anything about any of my scripts. So yes, ridiculous. > > Anyway, this happens when you would like to share or help, and people > are ready to show off remarking silly things without investigating a > little bit (e.g. with the updated version) for a death project like > that, as death is IE4, still there for case studies like those Thomas > is doing with code that should be compatible with IE4. I don't know what studies Thomas is doing, nor do I know what a "death project" is. Is it anything like death metal? > > @Thomas, I do believe you lack of sarcasm (C=64), while I have never This is not a blog you know. [...] > > Finally, I will learn to quote, Godspeed. ;) > but too often this ML is just a show It's not a mailing list either. > off place with zero outcome and few valid points ... No, that's how insecure and/or ignorant people respond to valid criticism (e.g. "aw, UR just showing off"). > I do hope this ml Again. > will grow up some day, so far I have read too often just "blame for > free to become famous" behaviors, annoying for both seniors and > juniors, useless for the community. > How about strongly criticizing where strong criticism is desperately needed and (slowly) changing the world for the better? No good in your book? Hey, I saw a niche and I filled it. My intentions in dispensing such criticism were always good, even if the pills seemed bitter to most readers (which has brought a lot of undeserved negativity my way when people should have concentrated on the messages). And making money off it is just a welcome side effect. I've paid my dues (up to #6 all time here last I checked). So sue me. ;)
From: Andrea Giammarchi on 20 Mar 2010 15:45 P.S. Boolean.isInstance = function (o) { return !!o && o.constructor === this; }; Boolean.isInstance(false); // false maybe a generic isInstance, whoever will use it, should be more like: Boolean.isInstance = function (o) { return o != null && o.constructor === this; }; Regards
From: Thomas 'PointedEars' Lahn on 20 Mar 2010 15:47
Andrea Giammarchi wrote: > On Mar 20, 1:43 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote: >> Thomas 'PointedEars' Lahn wrote: >> > Andrea Giammarchi wrote: >> > > So, how can you get confuse about that variable called __proto__? >> > >> > (It is a function _argument_, not a variable.) How can you be naming >> > an function argument like that? >> >> It can be harmful. Not only confused readers, but can pollute Scope >> Chain in strict implementation of ECMA-262-3. If `__proto__` is mimic >> of [[Prototype]] property, that can change Prototype Chain of VO. And >> during Identifier Resolution will be lookup in Prototype Chain of next >> object in Scope Chain. So in theory that property name of VO is >> harmful: >> >> var x = true; >> (function () { >> var __proto__ = {x : false}; >> >> print(x); //? >> >> })(); >> >> I can't see any implementation there print "false", but in theory can. >> So it's depend by implementation of AO/VO and definitely i can't use >> Identifiers like this. >> >> 1. Confuse readers >> 2. In some implementations can pollute Scope Chain. Of course that >> point is only in theory. > > dude, I do believe you are looking for this: > > var x = true; > with({}){ > (function () { > __proto__ = {x : false}; > alert(x); > }()); > } > > which as you know, is different from this: > > var x = true; > with({}){ > (function (__proto__) { > alert(x); > }({x : false})); > } It is not much of a difference, though. You miss the point. In both cases, if the Variable Object of the function execution context has a __proto__ property, the value of that property can be changed with potentially disastrous effects as the Variable Object is in the scope chain of such an execution context. (Only if the VO does not have such a property, you would be augmenting the Global Object with the property in the first case, and the effects in the second case would be negligible.) > however, I will never use that function as it was written, it was a > proof of concept, and nothing else, I am fine with instanceof > operator, I don't care about Commodore 64 ;-) You really want to take notice that the last original C64 shipped well before JavaScript was even invented. That is, unless you want to further make a fool of yourself here. And ISTM you don't care about IE/MSHTML 5 either, or mobile applications that might not implement all features of ES 3 in order to save memory. 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) |