Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.mixmin.net!weretis.net!feeder4.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <4756074.nmYHGREfxK@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Thu, 25 Oct 2012 23:18:10 +0200 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <722e889us0ep0mra233907giq2nnolqhge@4ax.com> <3335047.320Uf1SXUN@PointedEars.de> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 185 NNTP-Posting-Date: 25 Oct 2012 23:18:11 CEST NNTP-Posting-Host: ad8844c6.newsspool4.arcor-online.net X-Trace: DXC=`7ahD]\ND?efF8a^:6>b7e4IUKK`YMeRZD8g?;f5AkOH7E`dLk X-Complaints-To: usenet-abuse@arcor.de Xref: csiph.com comp.lang.javascript:16873 Stefan Weiss wrote: > I've been waiting for this... It seems that every time I post code to > this group, I get a reply filled with pedantic nitpicks and irrelevant > criticism from you. I do enjoy constructive feedback, but all this > disagreeing for the sake of disagreeing is a waste of everyone's time. > Especially when you intentionally misinterpret short code examples as > something they were never meant to be. I did not want to comment on that nonsense anymore, but I am finding now that it needs to be said for once: What kind of sorry luser are you that you think I would care about the name on any posting (short of pseudonyms, which is another issue), that I would actually care to use the little free time I have to target your (or anyone's) postings specifically? You need to be strong now: You are not that important (to me). You have to face the fact that so far you happen to have been posting mostly bad code. It does not matter if that code was just an example. A bad example is a bad example. It is misleading at best. So it boils down to this: If you do not want your code to be commented on, do not post it. If you want more favorable comments from me on your code (which is entirely possible), post better code. As for examples, you should post better examples. And I encourage you and everyone else to discuss *my* code with me, in public if you want. Many have found that rewarding already, and so do I. But you better bring good arguments. > On 2012-10-24 21:57, Thomas 'PointedEars' Lahn wrote: >>> // DOM0 event handler >>> document.onclick = function (evt) { >>> var e = evt || window.event; >>> ... >>> }; >> >> This is error-prone if `evt' refers to a host object, and unnecessarily >> inefficient. And document.onclick? > > This is a simple example of one very common usage of the || operator, > not an endorsement of DOM0-style event handling, so yes, document.onclick. > > As for error-prone, that's a huge exaggeration. I do not see how "error-prone" can be exaggerated. This code is prone to errors by the very nature of host objects; IOW, it is error-prone. > It's true that the event object is a host object, So you noticed. > but this particular form of checking for an event object as the first > argument has been widely used without problems since the mid 90s. > Defensive programming is a good habit, but it can be carried to far. It is not logical to use an approach that is prone to more errors than another approach, especially when that other approach is simpler, too. > And "inefficient"? Yes, *unnecessarily* inefficient *by comparison*. > In a click handler? Yes, especially in event _listeners_. > This statement will be evaluated (at most) once every time the user > clicks. If that was true, what do you need the _listener_ for, then? > I'm quite certain that any difference in performance between this example > and whatever you would offer as an alternative cannot even be measured > under these circumstances. Your logic is flawed. The performance benefit of `||' is negligible, too. >>> // initialize a "namespace" object without overwriting it >>> var myLib = myLib || {}; >> >> This is unnecessarily complicated. An `if' statement will do better and >> will be slightly more efficient. > > So you would prefer one of these? > > if (!myLib) { > var myLib = {}; > } > > if (typeof myLib == "undefined") { > var myLib = {}; > } I am preferring the second one in JSX. > What I wrote looks less complicated to me, YMMV. I think it is easier to explain with the `if' statement – especially to a beginner – why the variable may have the `undefined' value before assignment, and why the assignment would not take place when it has not. > but in the end it's just a matter of personal taste. No, because your approach, and the first alternative to that which you offered, performs implicit type conversion, and cannot be easily adapted to other properties; mine does not, and can be, respectively. > As with the first example, the efficiency of this statement is completely > irrelevant in the typical case (i.e., at the beginning of an included > file). Your version may save a single assignment, and only if myLib > already exists. Why worry about such details? Your logic is flawed. Why worry about using `||' to begin with? Because it looks cool? >>> myLib.myFunc = function () { ... }; >>> >>> // call a method on an optional argument >>> function findParagraphs (parentEle) { >>> return (parentEle || document).getElementsByTagName("p"); >>> } >> >> This can be error-prone. In particular, there is a problem when >> expression in the `||' operation is a reference to a Function instance. >> Some functions can only be called as methods of an (specific) object. > > You're imagining things, my overly critical friend. No, and I am not your friend. > As you can guess from the code, this function is intended to be called > with an element node, or no arguments. Pass an unsupported argument and > you will get an error. If that's your definition of error-prone, you will > need to check each end every argument in every single function. Sure, > that's possible, but if you do that, stop complaining about inefficient > code. Your function will fail if the element object in question does not implement the getElementsByTagName() method, and it will do so in a way that is hard to debug. >>> // combining && and || >>> function textOfFirst (parentEle, eleName) { >>> var ele = parentEle.getElementsByTagName(eleName)[0]; >>> return ele && ele.firstChild && ele.firstChild.data || ""; >>> } >> >> This is error-prone as the return type would vary (one of Null, Element >> or descendant, Text, or String) depending on runtime conditions that one >> has virtually no control over. (In fact, the first line is error-prone >> already as null has no properties). To be avoided. > > Please explain how this function can possibly return anything other than > a string (under non-pathological* circumstances). Yes, I was mistaken. In fact, calling the function can only have the following outcomes under those constraints: - A `TypeError' exception is thrown because a value that refers to or can be converted to an object was not passed for `parentEle'; - A `TypeError' exception is thrown because the object referred to by `parentEle' does not implement the getElementsByTagName() method; - A `TypeError' exception is thrown because the getElementsByTagName() method returns `null'; - A non-empty value of type String is returned, which may or may not be the full text content of the first child text node, if any; - "" of type String is returned. > Again, if you insist on passing unsupported arguments to a function, you > deserve what you get. Obviously you have not thought this through sufficiently. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, (2004)