Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.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: <1810646.Zi7hGo9um1@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Sat, 05 Jan 2013 20:46:42 +0100 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+&. <1512443.gQHv90F1im@PointedEars.de> <2329900.uRMUlLskrn@PointedEars.de> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 114 NNTP-Posting-Date: 05 Jan 2013 20:46:43 CET NNTP-Posting-Host: f01a1227.newsspool3.arcor-online.net X-Trace: DXC=>X_if[B?ILdf1oJaJ0@dmgMcF=Q^Z^V3h4Fo<]lROoRa8kFaDZm8W4\YJNlb@mF9jNikdeWWB88 Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >> > Thomas 'PointedEars' Lahn wrote: >> >> [You] should not simply return in the second branch in Version 2, >> >> [because >> >> calls will fail then; you should return a reference to a Function >> >> instance with an empty function body. >> >> > Disagree with that. Then the calling code would have no way of knowing >> > whether the function does anything useful. >> >> (For brevity, I am using “function” instead of “referred Function >> instance” from here.) >> >> That is not so. With an empty function body the returned function can be >> called *and* a called function returns “undefined” if it cannot do >> anything useful. > > Lots of functions return undefined, even after they have done > something useful. Non sequitur. I was referring to *this* *example*. >> That would be different from it returning “null”, *and* an >> advantage over returning a non-callable value from the >> function-constructor. > > What function constructor? The OP is conditionally defining a function > based on whether a needed element exists. See my follow up. I have taken the liberty of calling that a “function-constructor” (sic!). >> My point is that the latter should return a function here as the rest of >> the code hinges on the callability of the returned value. And if I am >> not very much mistaken, this is the pattern that you are employing in My >> Library, too. > > I think you have that backwards. My Library does leave API properties > undefined to indicate that there is no method available. In that case I must say that I do not think it is wise to leave it to the caller to check for the existence of an API feature, and you will observe that in JSX I am returning “undefined” or “null”, e. g., my getElementById() emulation returns “null” if none of the available approaches are supported. That way you can write, for example … = (function () { var _getElementById = jsx.dom.getElementById; return function () { var foo = _getElementById("foo"); if (foo) { /* do something with #foo */ } }; }()) and if none of the gEBI() approaches is going to work simply nothing will be done, the same as if there is no element with that ID. Why bother about the difference? You cannot get to an element object, so leave a possible related element as it is, and refrain from doing what depends on the existence of the element. > The dynamic nature of the API allows the calling code to make intelligent > decisions *before* calling API functions. Sometimes the decision is to > leave the document alone. A function that does virtually nothing leaves the document alone. With your approach you are not allowing, you are *forcing* the caller to make the decision, by *forcing* them to check whether what is supposed to be a method is not a method at all before they call it, in order to avoid a TypeError exception to be thrown. I do not think that is a terribly good idea. The users of such code are paying for a slightly smaller memory footprint with greater runtime for checks that have already been done by the library, *each* time they use the library feature. Or they would have to cache the test result. Why would they want to use a library then? Is not a main goal of a library to make programs that use it *easier* and *shorter* to write, and *less* complex to the developer; to provide *transparent* access to native features? >> > It's a variation of the "unbreakable chain" pattern seen in jQuery: >> > >> > A().B().C().D()... >> >> Which is why *chaining* *can be* error-prone. Non sequitur. > > Yes, it *can* if D relies on C, C relies on B, etc. That's why we have > conditionals in programming, which is not to be confused with > rearranging patterns of CSS selectors and dollar signs until they seem > to do something right. :) There have been abuses of chaining, but you should not discount it so quickly because of a few bad examples. Especially when it is guaranteed that a method will return a reference to a certain type of object, chaining can be most useful and time-saving. Given sufficiently advanced method code, debuggers are sophisticated enough to tell you what exactly went wrong in a chain, so that is hardly a good argument for not using it. > And no, it's not strictly the same problem as I have with your > suggestion about the empty function. Good. 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,