Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #17962

Re: Two versions of code - advantages and differences

Followups directed to: comp.lang.javascript

Show all headers | View raw

David Mark wrote:

> 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, <f806at$ail$1$8300dec7@news.demon.co.uk>

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-03 22:58 +0100
  Re: Two versions of code - advantages and differences Stefan Weiss <krewecherl@gmail.com> - 2013-01-04 00:41 +0100
    Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-04 09:15 +0100
      Re: Two versions of code - advantages and differences Gregor Kofler <usenet@gregorkofler.com> - 2013-01-04 11:26 +0100
        Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-04 14:29 +0100
          Re: Two versions of code - advantages and differences Gregor Kofler <usenet@gregorkofler.com> - 2013-01-04 14:56 +0100
            Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-04 16:52 +0100
    Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-04 09:19 +0100
  Re: Two versions of code - advantages and differences Gregor Kofler <usenet@gregorkofler.com> - 2013-01-04 11:25 +0100
  Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-04 15:31 +0100
    Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-05 08:37 -0800
      Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-05 18:14 +0100
        Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-05 10:51 -0800
          Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-05 20:46 +0100
            Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-05 17:12 -0800
              Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-06 17:43 -0800
              Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-07 03:58 +0100
                Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-06 19:23 -0800
                Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-07 05:19 +0100
    Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-06 22:30 +0100
      Re: Two versions of code - advantages and differences Stefan Weiss <krewecherl@gmail.com> - 2013-01-07 02:35 +0100
        Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-07 22:45 +0100
      Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-07 04:36 +0100
        Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-07 23:06 +0100
          Re: Two versions of code - advantages and differences Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-01-08 12:35 +0100
            Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-09 08:34 +0100
  Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-05 09:13 -0800
    Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-06 11:09 +0100
      Re: Two versions of code - advantages and differences David Mark <dmark.cinsoft@gmail.com> - 2013-01-06 12:56 -0800
        Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-07 22:53 +0100
  Re: Two versions of code - advantages and differences Luc Yen <luc@goal.tw> - 2013-01-05 12:54 -0800
    Re: Two versions of code - advantages and differences Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2013-01-06 21:38 +0100

csiph-web