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: Thomas 'PointedEars' Lahn on 10 Nov 2009 20:43 Garrett Smith wrote: > It is s silly presupposition that each function needs documentation. > > Comments often do lie and this happens inadvertently when the program > changes. Don't drink and derive! 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: kangax on 10 Nov 2009 21:39 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: >>>>>> 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/ Yes, from what I remember, Mozilla makes regex objects callable without actually giving them [[Call]]. In WebKit, on the other hand, regex do have [[Call]] and so typeof returns "function", as per specs (native object + has [[Call]] == "function"). You can find few related discussions on es-discuss ML's. I mentioned it recently among some of the issues revealed through Sputniktests � http://thinkweb2.com/projects/prototype/sputniktests-web-runner/#typeof-new-regexp-function > > 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). It's no surprise that ES3 specs are hard to follow and full of ambiguities. A year ago, the only way I could understand certain things in specs is with the help of wonderful explanations by Cornford and Lasse in the archives (on related subjects). Your last question on es-discuss proves how hard it could be to discern specs correctly. ES5, fortunately, takes care of some of these uncertainties. > >> 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. I have no experience with other languages, but I still find type checking useful. I find it easier to read and cleaner overall to have `isArray(something)` rather than `typeof something.length == "number"`. When I read the latter one in the code, my mind still automatically translates it to the former one � "Oh, ok... here we're checking if something is array...". It's not a big deal, though. I don't care much which one to use. I just prefer abstracted type checking, as I find it to convey overall meaning better. That's all, really. [...] > > Typechecking adds overhead to the code and increases call stack length. Well that much is obvious :) So is every other kind of abstraction, doesn't it? > > [...] -- kangax
From: kangax on 10 Nov 2009 21:45 Thomas 'PointedEars' Lahn wrote: > 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. > > The latest test results for the local ECMAScript Support Matrix (checked in > yesterday) support that assessment. Transposed: > > Feature: !== > Title: Strict Equals operator > JavaScript: 1.3 > JScript: 5.1.5010 > ECMAScript: 3 > JSCore: 525.19 > Opera: 5.02 > KJS: 3.5.9 > > Corrections for earlier versions of the implementations are welcome. Seems to work in Safari 2.0 as well. `userAgent` is: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/412.6.2 (KHTML, like Gecko) Safari/412.2.2 [...] -- kangax
From: optimistx on 11 Nov 2009 03:46 kangax wrote: > Garrett Smith wrote: .... >> Typechecking adds overhead to the code and increases call stack >> length. > > Well that much is obvious :) So is every other kind of abstraction, > doesn't it? Good point. If the user time in looking at the page increases from 10.00000 seconds to 10.000001 seconds due to 'overhead' and the program maintainer's time increases from 30 seconds to 40 seconds or more due to 'saving 0.000001 seconds' , which is better? (the maintainer is not necessarily the original programmer). When anyone is using the argument 'efficiency' would it be useful to estimate the difference numerically? It is true that 10.000001 seconds IS greater than 10.000000, and it is true that 40 seconds is greater than 30 seconds, but I think these are often extremely different matters.
From: David Mark on 11 Nov 2009 05:05
On Nov 11, 3:46 am, "optimistx" <optimi...(a)hotmail.com> wrote: > kangax wrote: > > Garrett Smith wrote: > ... > >> Typechecking adds overhead to the code and increases call stack > >> length. > > > Well that much is obvious :) So is every other kind of abstraction, > > doesn't it? > > Good point. If the user time in looking at the page increases from > 10.00000 seconds to 10.000001 seconds due to 'overhead' and > the program maintainer's time increases from 30 seconds to 40 > seconds or more due to 'saving 0.000001 seconds' , which is better? > (the maintainer is not necessarily the original programmer). > That's the problem with these libraries. They purport to save time (e.g. on keystrokes!), but the resulting illegible code, built on ever- shifting foundations ends up the opposite of a time-saver (i.e. constantly in need of costly attention and upgrades). In the case of typeof xyz == 'function' vs. an isFunction function, the former is clearer and faster. Who knows what isFunction is (until they look elsewhere in the code and comments?) If on looking it up, I found it was a single typeof operation, I'd wonder why the original author deliberately obscured its meaning, incurred performance penalties, etc. More often, the contents of an is* function turn out to be an ill-advised attempt to differentiate between host and native objects (e.g. host object methods vs. native Function objects). And don't discount the impact of function calls on performance, especially when manipulating the DOM. Their presence (or the lack thereof) is often critical to performance. |