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

Groups > comp.lang.javascript > #17997

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:
>> >> 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.
>> >> >>
>> >> >> 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.
>> > And if it can't find the element? It also returns null, right?
>> Yes, AISB.
> 
> And that illustrates the problem; despite it being trivial in this
> case, it's still a problem.

I do not think so.  There has not been any problem both in trivial and non-
trivial cases, whereever you want to draw the line.  Perhaps you are just 
misunderstanding my approach.

>> > That's a trivial example that demonstrates the problem of trying to
>> > slap a static API on environments that are unknown until run time.
>>
>> I fail to see a problem with that approach.  In fact, ISTM the very
>> problem that you perceive in my approach (without it actually being
>> there) occurs with your approach.  Apparently you are testing
>> *everything* *too early*.
> 
> No, I don't think you understand. See my follow up.

If you mean the follow-up with “−1” lines that begins with about 50 lines of 
quote, I'll have to pass.  Get a newsreader, and learn to post.
 
>> If the purpose of the function is to find out whether an element object
>> is accessible in the used runtime environment, then it has to be called,
>> of course.
> 
> But calling an empty function shell instead is just a waste.

Not if it allows the calling code to be less complicated, and the call only 
to be wasteful in border cases.  Whereas the latter was one goal of a 
library.  Remember?

>> But that does not need to be its only purpose.  If the function can
>> be called to find out whether an element object is accessible, it can
>> return a reference to the corresponding element object at the same time. 
>> It should not be necessary to test if this wrapper function exists.
> 
> Yes, because you may need to know if the gEBI (or whatever) wrapper
> will be expected to work before you can reliably test it.

Then there can be another feature that tells you about it *if* you want to 
know.

>> >> 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.
>> >
>> > That TypeError is your friend.
>>
>> Actually, no.  There are too many cases in which a TypeError exception
>> may be thrown.
> 
> No idea what you are talking about.

RTFSpec.

> You will get a very predictable "Cannot call undefined value" (or
> something like that) at the exact spot that you attempted to call the
> unavailable method. What could be easier? On the contrary, if the code is
> calling empty functions instead... Yeah, good luck debugging in unexpected
> environments.

FUD.  Nothing bad happens with an empty function.  If something should have 
happened and it did not, then one knows where to look.  But, I repeat, that 
should be the domain of author of the wrapper, when testing it, not the user 
(unless both of them happen to be the same person).

> Won't have any idea what is going on at a glance.

With a TypeError you will not know at a glance where it comes from.

>> One is performing availability tests (here: feature tests).  Those are
>> the domain of the service provider (here: the library developer).
> 
> Host object feature detection is certainly the domain of the service
> provider.

And I maintain that all feature detection should be.

>> They belong *in the service* (here: in the library code), and should be
>> hidden from the user (here: the developer using the library).
> 
> Exactly. That's what all of my projects do.

No, you have your users test what My Library is capable of providing.

>> The other is using the service.
> 
> Well, I didn't have any confusion about that. :)

I think you do.  Using should not imply testing of *service* features in the 
user code.  That would not be abstraction, it would be shifting 
responsibilities.

>> The purpose of a service should be to make
>> tasks less complicated for the user;
> 
> Yes, like host object feature detection and testing. ;)

Why stop there?

>> in this case, for them to skip the intricacies of feature tests in their
>> code, so that they can concentrate on the business logic.
> 
> But, but, but... :)
> 
>> That means that the features that the service provides
>> should *always* be available, and therefore need _not_ be tested for by
>> the user.
> 
> There's where you go off the road. Some features cannot *always* be
> available,

Try to put yourself into the position of a (not so dumb) library user for a 
minute:

*Your* features *can* always be available.  I have just loaded them.  Why 
are they not there?

> nor should you have to try to force them to be available in
> some legacy browser (e.g. QSA in IE 7) that could just as well do
> without the enhancement that requires those features.

Why should I use your library which forces me to test *its* features instead 
of the native ones, when all I wanted is to *avoid* testing *features* by 
myself?  I simply want to get an object that I can manipulate, to implement 
my business logic.  Why are you not only not providing it, but actively 
*preventing* me from *trying* to get at it?

>> What requires tests on part of the user then is only that the service
>> (here: the library method) returns a value that is useful for them in
>> their use-case.
> 
> Returns a value that is useful to them? That doesn't make any sense.

It makes a lot of sense.

> You can't expect to call every function at the outset.

Nobody does.  But one can expect that if the library says it provides a 
feature that feature is always available.  Whether it does something useful 
in a certain environment is another matter altogether.

> You don't want to tangle up your application code with checks for returned
> undefined values.

Instead you tangle it up with a growing list of tests for features that may 
never be used.  Great.

> What exactly would you do at the point where the user clicked
> a command button (the most basic UI) and your API function crapped
> out. Throw up an alert (requiring more code of course) telling them
> not to push that button? :)

Nonsense.  It is the job of the user of the library to make sure that this 
case is handled, and the job of the library to make sure that it can be 
recognized.  But it is not the job of the user to make sure that the case 
can be handled using the library.  Because that is what the library already 
promised to provide, and that is why the user is using it instead of hand-
crafted tests.

> Cross-browser scripting presents unique challenges. You cannot treat
> it like other programming disciplines.

Yet you do.  For example, you are assuming – and misleading the users of 
your code into believing – that because something is available on the top it 
must be available at the bottom.

> You are too preoccupied with the most basic API function. See my
> follow up. Also, there are times when you need to know if gEBI (or
> related wrapper) is available before the document is ready.

You are too preoccupied with trying to be right, not seeing the obvious 
disadvantages of your design when it comes to be people who want to use it.
 
>> Not only because an all-in-one test is much more expensive, but also
>> because circumstances can change considerably between the point in time
>> when the feature test occurs and when the feature is used.  So the
>> interval between those two points in time should be short.
> 
> Nothing expensive about an "areFeatures" call (or equivalent boolean
> type conversion tests).

It is, in essence, a function call to make sure that you can make a function 
call, when you could have just made the second call.  Yes, the former *is* 
more expensive than the latter.  And as the first call invokes tests for 
features that may never be used in the program flow, it is considerably more 
wasteful.

>> >> Or they would have to cache the test result.
>> > Absolutely not.
>> Yes, they would if they were to optimize this approach.
> 
> Nonsense. One-offs are (by definition) called once. It's over at that
> point; nothing to optimize.

The optimization would be to test only certain features at certain times, on 
an as-needed basis.  What you call “one-off” I call a waste of resources, 
and a hindrance to software maintenance.

>> >> 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?
>>
>> > You bet. See my examples. ;)
>>
>> That is *not* transparent access.  Transparent access presupposes
>> availability of the provider, with *all* the services they provide.
> 
> Doesn't matter what you call it. This so-called "transparency" is
> generally impractical for cross-browser scripting. At a glance, it may
> seem like nirvana (and the opposite some sort of hell), but that's the
> wrong reaction. See the follow up post.

It would appear that you have deluded yourself into believing that you know 
everything.  That way lies madness.

-- 
PointedEars

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