Re: When is a function not a function?

<dhtmlkitchen@xxxxxxxxx> wrote:
On Sep 26, 1:29 am, Richard Cornford wrote:
<snip>
> Then I came across this.

> (!!fn && typeof fn != "string" && !fn.nodeName &&
> fn.constructor != Array && /function/i.test( fn + "" ))

> I'm sure it is wrong

That would depend on what you considered correct. It looks
like the subject of the test is expected to be any of a
javascript function (unwisely tested), a siring primitive,
a DOM element and Array or a value with falseness. Getting
into a position where it is necessary to make such a test
betrays very poor code design.

I think you meant "portrays" not "betrays". Am I right?

No, "betrays" says exactly what I intended to say.

That analysis would be right if they'd used ||, but they
used &&.

No, that analysis is correct because it uses &&.

I provided analysis of the problem on my site.

That is not what I would call it. It is a pity that you choose to
publish such things without first having them checked by someone who
knows this subject.

The problem is that this function returns true for
objects (of any type) that contain
"function" in the toString result.

It also may return false for object that are functions. The author is
clearly unsure about what it is that is being tested for, and so has no
criteria for identifying an effective test for that (if one exists).

(!!fn )....................falses are out.

A pointless test if the subject is not expected to potentially be a
value that has falseness.

(typeof fn != "string")....string values are out

A pointless test if the subject is not expected to potentially be a
string primitive.

(!fn.nodeName).............things with a truthy nodeName are out.

A pointless test if the subject is not expected to potentially be an
object with a true nodeName property. An expected characteristic of DOM
elements.

(fn.constructor != Array)..Arrays in same frame are out.

A pointless test if the subject is not expected to potentially be an
Array.

(/function/i.test( fn + "" ).anything else left can get
through, it just has to say "function".

So in what sense is my "analysis" not correct? "It looks like the
subject of the test is expected to be any of a javascript function
(unwisely tested), a siring primitive, a DOM element and Array or a
value with falseness".

It's not safe, but it's indicative of the problem of
typechecking in js.

Dojo has similar stuff.

The dojo version of isFunction is nearly as bad as it will also return
true for non-callable objects. Again the authors appear to be uncertain
of what it is they are testing for.

They claim that some built-in functions don't
return "function" for typeof.

They can claim anything they like, but if it were a true statement they
could state the environment in which this was the case and show a test
case that proves the point (or shows where their misconceptions lie).
Without that, and judging their competence by the code in dojo, I would
not trust them to have made an accurate analysis.

I have been unable to prove that
statement true.
<snip>

You should not need to. The person making the claim is the one
responsible for demonstrating it.

There are no circumstances under which a function object would result
in - typeof fn != 'string' - being true

No. typeof fn != 'string' should *always* be true.

Yes, it looks like I omitted a "not" between "being" and "true". One of
the consequences of rushing to get it posted before going to work on a
week day.

or its having a - nodeName -
property or a constructor property that was a reference to the
frame's
Array constructor (unless they had been explicitly added).

You're confused by thinking ||. The function uses &&

No I am not. To get a true result with the logical AND operation test
every individual sub-expression needs to evaluate to true.

Anyway, typechecking is an issue

Not really. Once you get used to properly employing a loosely typed
language it rapidly becomes a non-issue, and such testing is relegated
to the feature testing role alone. Hence my assertion that the test
betrays poor design. Before someone has the experience to cope with
loose typing they will be struggling to identify the types of things
from a position of being totally in the dark. This results in such
testing functions being passed almost anything at all, and so having to
jump through hoops applying tests that really should never be necessary.

<snip>
I had glanced at it previously and dismissed
it based on its resemblance to Prototype. Upon closer
inspection, it makes Prototype look inspired. Suffice
to say that anybody who recommends it hasn't read the
code. It's a horror show.

You know, it might not be very good code, but I think John
might be creative.

Being "creative", of itself, is of little significance. Masses of
dubiously code and all of those half-ass hacks were 'created' by
someone.

To be usefully creative it is necessary to first formulate a clear
notion of what it is that is to be achieved. It is evidence of this
clarity of comprehension that is absent from the testing code. Hence my
assertion that the test betrays poor design. Before someone has the
experience to cope with loose typing they will be struggling to identify
the types of things from a position of being totally in the dark. This
results in such testing functions being passed almost anything at all,
and so having to jump through hoops applying tests that really should
never be necessary.

He's interested in these things, so improvement is
inevitable.

That may be likely, but not inevitable. It appears that becoming
satisfied with what you have done can seriously inhibit an ability to
improve.

The code above speaks of poor design, but at least it is
ECMA 262 conforming, so that is one up on Prototype.js.

What is not conforming in Prototype?
<snip>

ECMS 262 provides an EvalError that is to be thrown when the - eval -
function is called indirectly (in any way other than as - eval(
seomthing ); - ). It then gives implementations the option of not
throwing that exception. ECMAScript conforming code has no choice but
assume the worst case (that the exception will be thrown), while
Prototype.js makes the assumption that no implications will (ever) throw
that exception. Thus it sacrifices ECMAScript compatibility (and so all
hope of its ever being cross-browser) and ends up being dependent upon a
limited set of known (current) implications where the exception can be
observed not to be thrown.

Richard.

.

Relevant Pages

  • Re: Analyzing this Progression
    ... 7ths of 7th chords resolve downward. ... No, it's not an exception. ... the lower member rises or falls. ...
    (rec.music.theory)
  • Re: A C++ Whishlist
    ... Java is annoying enough with its exceptions to the operator overloading ... What's the point in "catching" an exception for a statement where you ... "Je ein Stueckchen Kreppsohle an die Fuesse eines Hamsters kleben. ...
    (comp.lang.cpp)
  • Re: Jon Skeets thread pooling sample
    ... that decision - I can't think of a good reason why the name of a thread has ... > 4) Add some sort of exception logging for this and the other events. ... It needs to be set before the 1st callback occurs ...
    (microsoft.public.dotnet.general)
  • Re: bizarre malloc problem
    ... > Snis Pilbor wrote: ... Debugging indicates the exception is indeed ... > the heap. ...
    (comp.lang.c)
Loading