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 16:52 On Mar 20, 9:24 pm, David Mark <dmark.cins...(a)gmail.com> wrote: it was even kinda interesting before the end ... > > As I have said, all your base are belong to us. > .... if you like to think it, please feel free to do it (btw, recycled typo not even fun anymore ... did you play only that game?) However, most web servers are still configured to rely into userAgent strings to redirect pages, serve files, etc etc ... you talk as if you can create the perfect script without updates etc etc ... most developers simply assume what is just about programming: software MUST be updated, nobody has been able to write a perfect software so far .... uh wait, I mean you a part ... Features detection is a partial solution, runtime methods/callbacks compilation is another imperfect, still good, improvement. It does not matter how abstract is your code in the most chaotic panorama with at least 20 different VMs (client/server), whatever we do, there could be a case where the feature detection, created *observing* current browsers behavior, will simply fail because of new behaviors, gotchas, inconsistencies, etc etc ... we don't have a crystal ball, ... I mean, you a part ... Anyway, surely features detection are a better answer, but at the same time, if *you* decide to change your browser agent string, *you* are the only one responsible for problems you are causing to yourself ... isn't it? So who has the best real cases solution against code compactness and loading time? (1000 features detections means lots of "wasted" and precious milliseconds) Unfortunately, still zero outcome, interesting reading tho, but no effective bullet proof solution suggested or presented here. Maybe because it's not that simple? Nice try tho Regards
From: David Mark on 20 Mar 2010 17:21 Andrea Giammarchi wrote: > On Mar 20, 9:24 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > it was even kinda interesting before the end ... Speak for yourself. :) > >> As I have said, all your base are belong to us. >> > > ... if you like to think it, please feel free to do it (btw, recycled > typo not even fun anymore ... did you play only that game?) What game? > > However, most web servers are still configured to rely into userAgent > strings to redirect pages, serve files, etc etc ... Like hell they are. Server side sniffing is not in widespread use, except by the most incompetent of server administrators (who should really be digging ditches instead). > you talk as if you > can create the perfect script without updates etc etc That's a common childish reaction. The point is that there is a _huge_ difference between nearly at the pinnacle and nearly at the pits. Do you understand that scripts may sometimes need updates, despite the best intentions/practices of the author? Granted, My Library must seem like magic compared to most. :) On the other end of the spectrum are scripts that are _designed_ to fail (i.e. they are written based on _today's_ observations for agents that are guaranteed to change, at least in some ways, in the future). Granted, they don't change as much or as radically as they used to, so there would seem very little justification for relying on script written by such misguided people. > ... most > developers simply assume what is just about programming: software MUST > be updated, nobody has been able to write a perfect software so > far .... The "nobody's perfect" excuse does not really apply to UA sniffing in browser scripts. That's like losing a basketball game 103-0 and claiming some sort of moral victory that you didn't score negative points. Again, perfection is at one end of the spectrum and the pits at the other. Sound practices will produce scripts that can approach perfection, poor practices all but guarantee the pits. > uh wait, I mean you a part ... Wait for what? > > Features detection is a partial solution, runtime methods/callbacks > compilation is another imperfect, still good, improvement. Feature detection and testing are sound practices. One-offs functions is a useful technique. > > It does not matter how abstract is your code in the most chaotic > panorama with at least 20 different VMs (client/server), Wow! 20 different ones! So, uh I guess you won't want to write 20 different branches based on your observation of each because then when one of them changes... :) > whatever we > do, there could be a case where the feature detection, created > *observing* current browsers behavior, will simply fail because of new > behaviors, gotchas, inconsistencies, etc etc ... we don't have a > crystal ball, ... I mean, you a part ... Again, that is not an argument (though it has been masquerading as one for years). Just because sound practices are not infallible does not justify poor practices. If you install smoke detectors and your house ends up burning down anyway, it doesn't stand to reason that you should try something inferior (like a barking dog) for your new house. > > Anyway, surely features detection are a better answer, but at the same > time, if *you* decide to change your browser agent string, *you* are > the only one responsible for problems you are causing to yourself ... And that one. You still don't get it. The UA string is designed to deceive by the _browser developers_, as well as sophisticated _end users_. They are trying to get past incompetent scripts. If your scripts sniff this string in the bizarre assumption that it is going to be usable to determine the features present in the environment, then you the author are to blame for writing an incompetent script. You are part of the problem and people (developers and users alike) change the UA string to try to solve that problem. > isn't it? So who has the best real cases solution against code > compactness and loading time? (1000 features detections means lots of > "wasted" and precious milliseconds) That argument is years out of date. There is no rule that says feature detection must take place on load. It can (and often is) done on load, but can also be done on the first call of a function (the so-called lazy pattern). And competently written scripts don't repeat feature tests (it's one and done), whereas incompetently written scripts invariably check the UA string (a property of a host object, just as feature detection often checks) every time through. > > Unfortunately, still zero outcome, interesting reading tho, but no > effective bullet proof solution suggested or presented here. Maybe > because it's not that simple? Nice try tho > All I can ask is where you have been for the last two and a half years or so (that's roughly how long I have been in here saying the exact same thing, posting myriad examples, explaining and re-explaining the same concepts, etc.) I just repeated it in abridged form for you here. Your defensive reaction (which is very typical for neophytes) speaks volumes. You've got a long way to go.
From: Thomas 'PointedEars' Lahn on 20 Mar 2010 17:32 Andrea Giammarchi wrote: > Thomas 'PointedEars' Lahn 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? I am getting the distinct idea that you have been trying to waste my time all along. >> 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 ... Nobody sane uses `new Boolean', though. > I strongly doubt about your code, whatever you think > about my mental sanity. I am pretty sure about it now. > 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. Which is why *you* would use a isInstance() instead of `typeof' ... Get better. > 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 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ I have never suggested this. > your SUPADUPA o.constructor === this with a pointless boolean cast > before, followed by a not .... performances and mobile devices > anybody? You are starting to write in gibberish. ISTM you should take your pills now. > Thanks Asen in any case for the only valid outcome came out of this > topic. Not all arguments that you are incapable to comprehend are not valid. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Thomas 'PointedEars' Lahn on 20 Mar 2010 17:38 Andrea Giammarchi wrote: > Thomas 'PointedEars' Lahn 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); > } That is _not_ the same code that I had commented on, and it is unnecessarily complex by comparison, but I'll bite. > where is exactly the disaster? If either Variable Object had a `__proto__' property that is not read-only, subsequent accesses to `a' from within the function would be successful, because when a function execution context is entered, a VO is created and augmented with properties named for each named argument and each variable. In particular, subsequent accesses to `o' would not target the global variable `o' but the property `o' of the object referred to by `__proto__' if it had one. This would be the scope chain (horizontal) and prototype chains (vertical) with regard to the returned function's execution context: (7) (5) (3) Ident. res. VO (Global Object) <--- o <--- VO (local) <--- VO (local) <---------- | | | | (1) | (8) (6) | (4) | Ident. res. | (2) | impl.- v v v `----------> Object.prototype __proto__ [[Prototype]] dependent By comparison, your original code, which I had commented on, -- > > > 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})); > > > } -- would create the following scope chain and prototype chains then: (7) (5) (3) Ident. res. VO (Global Object) <--- o <--- VO (local) <--- VO (local) <---------- | | | | (1) | (8) (6) | (4) | Ident. res. | (2) | impl.- v v v `----------> Object.prototype [[Prototype]] __proto__ dependent So you see that your forging your code here does not make much of a difference with regard to the situation described above. > for a function created to test an argument? it was NOT a generic > funciton, it was a closure with a specific aim An aim missed at that. Your introducting `with' here also does not make sense. `with' appends the object referred to by its parameter to the *front* of the scope chain; that is irrelevant with regard to the VO of either function execution context. >> 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? An example of what? (You have only quoted a part of the statement.) >> 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? Memory. (Can't you read?) > Do you know what is my current job? No. (Is it relevant?) > Can you enlighten us how that WRONG check could save memory for mobiles? Can you reword this question so that it make sense? > And please provide a list of mobile devices without instanceof support, > thanks, I will tell you how important JavaScript is for these devices. I have no list, but I have read here from people I trust they know what they are saying and doing (so not you) that there are relevant mobile devices that do not implement all features of ES 3 to save memory. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Andrea Giammarchi on 21 Mar 2010 10:51
On Mar 20, 10:21 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > You've got a long way to go. > dude, I am sorry, but I have never learned anything new from your posts here, while your vision is sandboxed in your arrogance. You are zero outcome granted, you reply more childish than you think I am, and unfortunately for you, you are not able to consider other points of view. Features detection as "one shot" are precious milliseconds, libraries are rarely loaded "on load" and since there is no library which aim is to provide only features detections once and for everybody else (we all rely in our feature detection) the total amount of wasted milliseconds in a classic environment where scripts must interoperate and usually are more than one, could be relevant, it depends which hardware you are dealing with. The lazy pattern we all know and surely not because of you, able or not to create a "one off" specific function, has it cons as well because it inevitably requires more code and more logic (more stuff to maintain as well then) and again, while performances could be best ever, the script loading time will be improved. Now, which one is more important, more than 50ms for each download due script size or a runtime check able to produce the same output in a way that does not mean anything being an operation performed in 0.05 ms? It's all about requirements, but you are so professional and religious about what you think that as I have said your knowledge is sandboxed. Multiple browser sniffing? I have rarely seen such technique, the moment you need to know if the MSIE string is there in a proper order, checking out those agents with MSIE compatible, is the moment you create a variable. The moment you need these checks all over the place, is the moment you have an object with these info. The moment a new browser will come out changing UA, you'll have only one single place to update with these changes or a single place to improve. The fact IT changes every bloody day means you don't have the best answer, you can only assume you have these answers until somebody else will come out with a better option for different reasons and that day libraries developers will be flexible enough to understand if for they requirements that new solution is worth it. This is what I think is a good developer, other people with the truth in their hand and "everything else is bullshit" are the only one with a long way to go. Regards |