Identifier like "_", "$", etc.
in [JavaScript]
|
Prev: A practical exercise: fighting maskons
Next: FAQ Topic - How do I get a jsp/php variable into client-side javascript? (2009-11-10)
From: David Mark on 10 Nov 2009 15:34 On Nov 10, 9:40 am, Tim Down <timd...(a)gmail.com> wrote: > On Nov 9, 10:34 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > > if (atype !== 'object') return false; > > > Strict comparison is unneeded here. > > I'm sure you've answered this before, but what is your beef with using > strict comparison operators when they're not needed? the only argument > I can see against it is the use of one extra character. Because it makes the code harder to read. If I see a loose comparison, I know the two operators are expected to be the same type. A strict comparison warrants further investigation to determine if it is needed (e.g. operand types can vary) or not. > > > And none of these "overloading" functions are conducive to good design > > anyway. If you consider a case that is do-able (e.g. string vs. > > function), it boils down to the typeof operator. So why wrap that in > > a function? > > The benefit of using isWhatever functions for the doable cases is that > you remove the possibility of introducing bugs by mistyping the > comparison string ("function", "string", etc.) that exists if using > inline typeof comparisons. You don't have to compare the typeof result to string literals. In fact, in a large project, I'd advised against that for just this reason.
From: Garrett Smith on 10 Nov 2009 15:42 kangax wrote: > David Mark wrote: >> On Nov 9, 6:27 pm, kangax <kan...(a)gmail.com> wrote: >>> David Mark wrote: >>>> On Nov 9, 3:41 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote: >>>>> I read ajaxian.com. There i found one post which presented one new [...] Ajaxian is a pop blog. Do not expect that to be a reliable source of information on how to program. >>>> Well, this one is just silly. Could use typeof for Function objects, >>> Nope. Did you forget what typeof reports for regex objects in webkit? >> >> Of course not. Second sentence in the documentation for such a >> function (after host object warning) should be "Do not use with RegExp >> objects". It stands to reason that a design that sets out to discern >> between Function and RegExp objects is a design in need of a rewrite. > > But it's not even about discerning. What if regex ends up as an argument > of your function and that function invokes `call` on it after testing it > with `typeof`? regex don't have call (unless you give it to them) so it > will fail. > javascript: alert( Function.prototype.call.call(/a/, "a") ); Webkit: elerts "a" Tracemonkey: TypeError: Function.prototype.call called on incompatible /a/ That's odd. Seems in Tracemonkey, a RegExp is callable without implementing [[Call]], or ? A bug in there syntax extension, due to internal typechecking for RegExp, as: typeof /a/ Tracemonkey: "object" javascript: alert( /a/("a") ); elerts "a" The documentation argument... It is s silly presupposition that each function needs documentation. Comments often do lie and this happens inadvertently when the program changes. Good comments help to explain code that is difficult, unusual, or unintuitive. Bad comments lie, or don't lie but clutter the source code. Many won't read the documentation of others (including pertinent specifications, as witnessed recently on this NG). Developers often skip right to the "what does it do" (functions, examples, or tests). > Too many limitations and exceptions is also annoying. What "too many" > means is of course subjective, and what's annoying to me might be fine > to you. > > I don't see much harm in employing [[Class]] based test, though. > Where is typechecking necessary or useful? Typechecking justifications are usually based on attempts to make javascript appear more like some other language. For example, to enabling fake overloading. A generalized typecheck would be unreliable in the general sense (fickle, dodgy host objects). Typechecking is not usually needed and doesn't work for host objects. It can be done inline, where needed. Typechecking adds overhead to the code and increases call stack length. [...] -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 10 Nov 2009 15:56 On Nov 10, 3:42 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > kangax wrote: > > David Mark wrote: > >> On Nov 9, 6:27 pm, kangax <kan...(a)gmail.com> wrote: > >>> David Mark wrote: > >>>> On Nov 9, 3:41 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote: > >>>>> I read ajaxian.com. There i found one post which presented one new > > [...] > > Ajaxian is a pop blog. Do not expect that to be a reliable source of > information on how to program. > > >>>> Well, this one is just silly. Could use typeof for Function objects, > >>> Nope. Did you forget what typeof reports for regex objects in webkit? > > >> Of course not. Second sentence in the documentation for such a > >> function (after host object warning) should be "Do not use with RegExp > >> objects". It stands to reason that a design that sets out to discern > >> between Function and RegExp objects is a design in need of a rewrite. > > > But it's not even about discerning. What if regex ends up as an argument > > of your function and that function invokes `call` on it after testing it > > with `typeof`? regex don't have call (unless you give it to them) so it > > will fail. > > javascript: alert( Function.prototype.call.call(/a/, "a") ); > Webkit: > elerts "a" > > Tracemonkey: > TypeError: Function.prototype.call called on incompatible /a/ > > That's odd. Seems in Tracemonkey, a RegExp is callable without > implementing [[Call]], or ? A bug in there syntax extension, due > to internal typechecking for RegExp, as: > typeof /a/ > > Tracemonkey: > "object" > > javascript: alert( /a/("a") ); > elerts "a" > > The documentation argument... > > It is s silly presupposition that each function needs documentation. That's the stupidest thing I ever heard. > > Comments often do lie and this happens inadvertently when the program > changes. So, you are projecting your own habits on the rest of the programming community? > > Good comments help to explain code that is difficult, unusual, or > unintuitive. Bad comments lie, or don't lie but clutter the source code. You sound like VK again. > > Many won't read the documentation of others (including pertinent > specifications, as witnessed recently on this NG). Specs aren't docs if they don't reflect reality. Seems you are still stewing about that thread. Get over it. > Developers often skip > right to the "what does it do" (functions, examples, or tests). So? If they don't read the documentation before using a function, then that's there problem. And that's true for any API. > > > Too many limitations and exceptions is also annoying. What "too many" > > means is of course subjective, and what's annoying to me might be fine > > to you. > > > I don't see much harm in employing [[Class]] based test, though. > > Where is typechecking necessary or useful? Thanks, professor. That has been the point all along. > > Typechecking justifications are usually based on attempts to make > javascript appear more like some other language. For example, to > enabling fake overloading. Why regurgitate all of this at this point? > > A generalized typecheck would be unreliable in the general sense > (fickle, dodgy host objects). Thank you. > > Typechecking is not usually needed and doesn't work for host objects. And again. > It can be done inline, where needed. So, you agree to agree on all of the points made? What was your point? > > Typechecking adds overhead to the code and increases call stack length. Certainly not the latter. I'm sure you mean that calling functions increases the call stack length.
From: Garrett Smith on 10 Nov 2009 15:56 Tim Down wrote: > On Nov 9, 10:34 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> if (atype !== 'object') return false; >> >> Strict comparison is unneeded here. > > I'm sure you've answered this before, but what is your beef with using > strict comparison operators when they're not needed? the only argument > I can see against it is the use of one extra character. > Agreed, focusing on that "issue" seems to miss the point. The strict equality operator (===), will have slightly faster performance in at least one implementation (JScript). The benefit is negligible. The cost of the one extra character is also negligible. > >> And none of these "overloading" functions are conducive to good design >> anyway. If you consider a case that is do-able (e.g. string vs. >> function), it boils down to the typeof operator. So why wrap that in >> a function? > > The benefit of using isWhatever functions for the doable cases is that > you remove the possibility of introducing bugs by mistyping the > comparison string ("function", "string", etc.) that exists if using > inline typeof comparisons. > Couldn't |isWhatever| be mistyped? If autocomplete is desirable, constants can be used. var FUNCTION = "function"; if(FUNCTION === typeof obj.eventHook) { obj.eventHook( {/*...*/} ); } Those constants would be munged. Performance would probably slower than string literal, though only by a negligible amount (when in same scope). Compared to the performance of calling isWhatever, the performance would be better (unless the interpreter provides some sort of inline optimization). -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Garrett Smith on 10 Nov 2009 16:05
Garrett Smith wrote: > kangax wrote: >> David Mark wrote: >>> On Nov 9, 6:27 pm, kangax <kan...(a)gmail.com> wrote: >>>> David Mark wrote: >>>>> On Nov 9, 3:41 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote: [...] > Typechecking adds overhead to the code and increases call stack length. > Correction: Calls to typechecking functions add overhead... -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |