QUESTION: Can a function be set up as a constant in JS?
in [JavaScript]
|
Prev: how to get url of script
Next: question of logic?
From: Andrea Giammarchi on 20 Mar 2010 15:52 On Mar 20, 8:39 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > Er, that's my line (not Michael's). > sorry Michael > > 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. > I don't remember when I wrote that code, and it has always worked fine for what I had to do by that time, sniffing included, a common technique in 2004 or before. > > I don't care for it. Not a bit. :) > so why bother ? just for fun ? As I have said, all your answers are zero outcome. I am sure you have lot of time to spend here, have fun then, please try to be more useful for the community as well, don't keep the fun all for you. Cheers P.S. which blog? which book? if you are superficial and you don't know things, again, why bother? do you feel better after?
From: Thomas 'PointedEars' Lahn on 20 Mar 2010 16:01 Andrea Giammarchi wrote: > 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; > }; OMG. Nobody, but nobody, wanted to present a generic isInstance() here; the purpose was merely to show that methods of Function instances can be useful. Nor would anybody knowledgable define or use Boolean.isInstance(). There's `typeof', you know (so much backwards-compatible that it did not need to be feature-tested even if that was possible). And please don't say "Boolean instance" now, or I will *seriously* have to doubt your mental sanity. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Andrea Giammarchi on 20 Mar 2010 16:03 On Mar 20, 8:47 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > > 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. > var o = {}; with(o){ (function(__proto__){ return function () { __proto__.a = 123; }; }({})).call(o); } where is exactly the disaster? for a function created to test an argument? it was NOT a generic funciton, it was a closure with a specific aim > > 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.) > example please? following same logic I have already used? > > 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. > a fool of myself? how exactly? because I have said that IE4 for me is Jurassic as C64 is? If this is a fool of myself, can I add the game boy, Super Mario, my Olivetti M24 in the list as well? I like foolish myself!!! > > 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. > In order to save what? Do you know what is my current job? Can you enlighten us how that WRONG check could save memory for mobiles? And please provide a list of mobile devices without instanceof support, thanks, I will tell you how important JavaScript is for these devices. Regards
From: Andrea Giammarchi on 20 Mar 2010 16:10 On Mar 20, 9:01 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Andrea Giammarchi wrote: > > 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; > > }; > > OMG. Nobody, but nobody, wanted to present a generic isInstance() here; the > purpose was merely to show that methods of Function instances can be useful. > so, you have merely purpose, my 7 years old code can be blamed and a proof of concept commented for 2 pages? > > Nor would anybody knowledgable define or use Boolean.isInstance(). There's > `typeof', you know (so much backwards-compatible that it did not need to be > feature-tested even if that was possible). And please don't say "Boolean > instance" now, or I will *seriously* have to doubt your mental sanity. > the constructor check is a natural fallback for typeof failure against new Boolean ... I strongly doubt about your code, whatever you think about my mental sanity. Usually, but maybe it's just me, when I write some helper I write it to optimize my code e.g. less checks, less code, more stability, and portability. Concepts such one function for all cases are daily basis stuff here, I am glad you think typeof o && Func.isInstance is a better trick than your SUPADUPA o.constructor === this with a pointless boolean cast before, followed by a not .... performances and mobile devices anybody? Be serious please, at least be constant! I stop this flame, have fun you guys. Thanks Asen in any case for the only valid outcome came out of this topic. Reagrds
From: David Mark on 20 Mar 2010 16:24
Andrea Giammarchi wrote: > On Mar 20, 8:39 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> Er, that's my line (not Michael's). >> > > sorry Michael > >> 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. >> > > I don't remember when I wrote that code, and it has always worked fine > for what I had to do by that time, sniffing included, a common > technique in 2004 or before. It was (and is) a common incompetent technique that was discarded by professional (and conscientious) developers around the turn of the century. At some point (hopefully very early) on the learning curve, aspiring browser script authors realize the futility of relying on a string of characters that is designed to deceive (e.g. browser developers and end-users use it to deceive incompetent browser sniffing scripts). Unfortunately, in 2010, we have this rogue's gallery of "major" JS projects still making inferences based on this arbitrary (and often deceitful) string: - Dojo - Prototype - YUI - Closure - Cappuccino - SproutCore ....and countless minors like the execrable "pragmatic" Base2 and many non-entity throwaway scripts as well. The jQuery project has since moved up one rung in the latter to object inferences, which are still based on pigeonholing _today's_ observations. http://www.jibbering.com/faq/faq_notes/not_browser_detect.html#bdOI Of course, it took years of beating them over the head with some very basic truths to move that mountain and I never did get a thank you note from Resig. :( So what is going on here? Are all of these people so stupid that they can't understand the cited article? No. They are simply relatively new to cross-browser scripting, which is a discipline that takes a long time to master and is unlike virtually any other field of programming. Of course, as programmers, they are arrogant, so they don't want to hear that explanation. The pitch for most of these projects is that browsers are wildly different, which is not really true these days, but was indeed the case when most of these people first started with browser scripting. The other thing they are selling is that browsers change rapidly so you need a team of "experts" to help you keep up. Again, this couldn't be more false for most contexts these days. It is particularly false for projects that need only concern themselves with major desktop browsers (or at the extreme, a subset of their versions). Of course, most sites on the Web don't have this luxury, but that hasn't stopped misguided Web developers from deploying scripts that behave as if they do (e.g. unreliable in anything but the very latest versions of a handful of major desktop browsers in their default configurations). Somehow, some way, this practice has come to be known as "saving time", despite the fact that it virtually guarantees the exact opposite. How has this happened? The developers of the scripts never learned cross-browser scripting (or are talking their time about it anyway), so they rely on outdated and misguided techniques like browser sniffing, which necessarily results in scripts pinned to _today's_ observations (what they refer to as "current" browsers). So they write lots of branches based on what they _observe_ (typically failing to understand the abstractions in play) and produce scripts that, at least superficially, seem to work today. Okay, but getting back to their pitch, if browsers change so fast and in so many different directions, how can it be useful to write logic based on _today's_ observations? That's where the whole movement vanishes in a puff of logic (or will vanish in the future anyway). If you really need people to watch browsers and write code (more like diaries) based on those observations to keep up with browsers, then it stands to reason that the same people will have to rewrite the same code indefinitely (and at an ever increasing frequency as the number of browsers in use increases). So, to anyone who can grasp basic logic, it should be clear that their time-saving pitch is completely flawed. They are basically selling a lifetime installment plan of rewrites, re-testing, re-deployment, support headaches (support plans are often part of the scam), etc. That's it. Now, as code is not written, debugged and tested instantaneously, it stands to reason that there will be gaps in synchronizing the observations, resulting code and (what must be compulsory) browser upgrades. These gaps will become wider as more browsers are introduced. Many of these projects have attempted to rationalize their illogical plans by claiming not to "care" about anything but the very latest browsers, but unfortunately, the end-users aren't going to care what the script authors care about. When your site starts having problems, they will get upset, perhaps calling for support from (or summary execution of) the owners, but more likely moving on to greener pastures. Often the argument is made that it doesn't make sense to take any action until complaints start rolling in, but that doesn't fly as most end-users don't feel it is their duty to complain (and Web developers have earned a justified reputation as less than amenable to criticism). And then there are the pseudo-intellectuals who will focus on the _past_ and say that if that's how it has been done for all of these years, it must be right (see Matt Kruse) and any voices to the contrary must be mad, idealistic, naive, whatever. It's all bullshit. Ah, but I digress... > > >> I don't care for it. Not a bit. :) >> > > so why bother ? just for fun ? Why bother with what? > As I have said, all your answers are zero outcome. As I have said, all your base are belong to us. > I am sure you have > lot of time to spend here, If you knew Time as well as I do... :) > have fun then, please try to be more useful > for the community as well, don't keep the fun all for you. Cheers Uh, cheers (I think). > > P.S. which blog? which book? if you are superficial and you don't know > things, again, why bother? do you feel better after? Since you ask, I feel a bit sick at the moment. You are dizzying. :( |