Should isHostMethod be added to the FAQ?

R

RobG

<FAQENTRY>

There has been frequent mention of the legendary "isHostMethod"
function in this group over the last 18 months or so in conjunction
with statements that "boolean type conversion is out" for testing host
method availability. While that may be so, trying to find the elusive
method in all the noise is pretty difficult.

I discovered this version posted by Thomas in February 2008[1]:

function isHostMethod(o, m)
{
var t = typeof o[m];
return (/^(function|object)$/.test(t) && o[m])
|| t == "unknown";
}

It is also difficult to find posts on why it is preferred to the more
common type converting tests. Perhaps it's time to add an FAQ entry
about testing host methods that briefly states why isHostMethod should
be used and includes the code (with appropriate attribution) so it can
be referenced and found more easily.

</FAQENTRY>

1. <URL: http://groups.google.com/group/comp.lang.javascript/msg/eceaf3fa529973ec
 
D

David Mark

<FAQENTRY>

There has been frequent mention of the legendary "isHostMethod"
function in this group over the last 18 months or so in conjunction
with statements that "boolean type conversion is out" for testing host
method availability.  While that may be so, trying to find the elusive
method in all the noise is pretty difficult.

I discovered this version posted by Thomas in February 2008[1]:

  function isHostMethod(o, m)
  {
    var t = typeof o[m];
    return (/^(function|object)$/.test(t) && o[m])
           || t == "unknown";
  }

That specific version from My Library, but to be fair, it's just
Thomas' old isMethodType with a few tweaks. Probably the most
important addition (and the simplest) is the detection of the
legendary "unknown" types, which MS has subjected Web developers to
since IE4. Most important thing to document is that is expected to be
passed (e.g. a host object and the name of a property known to be
implemented as a method.)
It is also difficult to find posts on why it is preferred to the more
common type converting tests.

There were a lot of discussions around when the CWR repository was
created (winter of 2007-2008 I think.)
Perhaps it's time to add an FAQ entry
about testing host methods that briefly states why isHostMethod should
be used and includes the code (with appropriate attribution) so it can
be referenced and found more easily.

</FAQENTRY>

1. <URL:http://groups.google.com/group/comp.lang.javascript/msg/eceaf3fa529973ec

I think it is a great idea. There are a couple of other variations as
well (e.g. isHostObjectProperty.) Peter's article(s) on the subject
summarize the pros and cons and offers different versions of each,
IIRC.
 
R

RobG

<FAQ***RY>
There has been frequent mention of the legendary "isHostMethod"
function in this group over the last 18 months or so in conjunction
with statements that "boolean type conversion is out" for testing host
method availability.  While that may be so, trying to find the elusive
method in all the noise is pretty difficult. [..]
Perhaps it's time to add an FAQ entry
about testing host methods that briefly states why isHostMethod should
be used and includes the code (with appropriate attribution) so it can
be referenced and found more easily.
</FAQ***RY>

1. <URL:http://groups.google.com/group/comp.lang.javascript/msg/eceaf3fa529973ec

I think it is a great idea.  There are a couple of other variations as
well (e.g. isHostObjectProperty.)  Peter's article(s) on the subject
summarize the pros and cons and offers different versions of each,
IIRC.

I guess you mean this one:

Feature Detection: State of the Art Browser Scripting
<URL: http://peter.michaux.ca/articles/feature-detection-state-of-the-art-browser-scripting
If on one volunteers in the meantime, I'll make a start and post it
later. Been kinda busy lately and have been spending most of my spare
time sailing.
 
W

wilq

<FAQENTRY>

There has been frequent mention of the legendary "isHostMethod"
function in this group over the last 18 months or so in conjunction
with statements that "boolean type conversion is out" for testing host
method availability.  While that may be so, trying to find the elusive
method in all the noise is pretty difficult.

I discovered this version posted by Thomas in February 2008[1]:

  function isHostMethod(o, m)
  {
    var t = typeof o[m];
    return (/^(function|object)$/.test(t) && o[m])
           || t == "unknown";
  }

It is also difficult to find posts on why it is preferred to the more
common type converting tests.  Perhaps it's time to add an FAQ entry
about testing host methods that briefly states why isHostMethod should
be used and includes the code (with appropriate attribution) so it can
be referenced and found more easily.

</FAQENTRY>

1. <URL:http://groups.google.com/group/comp.lang.javascript/msg/eceaf3fa529973ec


I was curious why the hell use regexp, so I made a test for that and
It is how I suppose to work... RegExp is slower than comparing to
simple strings. (Tested on firefox 3.06, Opera 9.63, Chrome 2.0.172,
IE 6).

Comparing to string has one main advantage: in case of first true
test, any next is not fired. So worst case is when we have a string
"object" in this case. But even for 3 diffrent strings for worst case
regexp solution is still 2 times slower (or even more - depending on
browser engine). This regexp solution might be speedup a little by
storing regexp function, and not create it every time isHostMethod
function is called, but surprisingly it does not change alot in
function execution time.

So I asking... where is this "ineficient" that Thomas speak about?
 
T

Thomas 'PointedEars' Lahn

RobG said:
<FAQENTRY>

There has been frequent mention of the legendary "isHostMethod"
function in this group over the last 18 months or so in conjunction
with statements that "boolean type conversion is out" for testing host
method availability. While that may be so, trying to find the elusive
method in all the noise is pretty difficult.

I discovered this version posted by Thomas in February 2008[1]:

My JSdocâ„¢ says:

* @author
* (C) 2003-2009 Thomas Lahn &lt;[email protected]&gt;

I presume Google Groups still has the first version, either here or in
de.comp.lang.javascript.
function isHostMethod(o, m)
{
var t = typeof o[m];
return (/^(function|object)$/.test(t) && o[m])
|| t == "unknown";
}

The version in <is more efficient and
less error-prone.

The local version of object.js (0.1.5a.2009062116) currently features
jsx.object.isMethod() which allows to pass an object reference plus an
arbitrary number of string arguments. This allows e.g. isMethod(Array,
"prototype", "slice", "call") and avoids repeated calls of isMethod().
However, it also precludes flags from being used as third, fourth aso.
argument which could help make this method more flexible (in particular, I'm
thinking about evaluation of a first string argument as in previous versions
which would avoid explicit `typeof ... != "undefined"' of the first argument
before call.) Although that could be accomodated with properties of the
Function object itself, or properties of jsx.object as well, I have not
decided on this yet. Suggestions?

Since the `typeof' operation has to be done in any case, I'm not sure if a
special method for host methods is really needed; currently I am only using
(jsx.object.)isMethod() for testing all methods. What do you think?
It is also difficult to find posts on why it is preferred to the more
common type converting tests.

Host objects tend to throw exceptions on type conversion when they don't on
`typeof', in particular host methods for which `typeof' results in "unknown".

In addition, host objects tend to "lie" about their features on type
conversion; they tend not to with type detection. For example, IIRC for a
time `document.all' type-converted to `true' in Gecko's Quirks Mode
(evidently that is no longer the case as of Firefox 3.0.11/Gecko 1.9.0.11);
by contrast, `typeof document.all' evaluated to "undefined" (and still
does). That was a reasonable approach, given that document.all.foo worked
(and works; for whatever twisted reasoning), but document.all.tags("div")
didn't (and doesn't, throws a TypeError).


PointedEars
 
R

Richard Cornford

On Jun 30, 9:07 am, wilq wrote:
I was curious why the hell use regexp, so I made a test
for that and It is how I suppose to work... RegExp is
slower than comparing to simple strings. (Tested on
firefox 3.06, Opera 9.63, Chrome 2.0.172, IE 6).
<snip>

The question of relative performance of regular expressions compared
with string comparison has come up before and on one occasion testing
revealed a significant factor that almost never seems to be considered
when people test the relative speeds' of things. I turned out that the
posted test-case (you have failed to post your test-case) showed
opposite results for different people running it. Having verified
that the browser/JS environments were equivalent in each case interest
widened to the hardware environment, where it turned out that the CPU
appeared to be a significant factor, with P-III processors producing
the results where string comparison was fastest and P-IV processors
producing the results where regular expressions were fastest.

The (unproven) theory was that the P-IV's longer pipeline was
favouring the regular expressions and hindering the simpler comparison
operations (with the overheads of flushing the pipeline after the
comparison). Intel has been shortening their CPU pipelines since the P-
IV, which would suggest the advantages might swing back to simple
comparison (though the machine I am sitting at right now has a P-IV
CPU).

Richard.
 
J

Jorge

(...)
The (unproven) theory was that the P-IV's longer pipeline was
favouring the regular expressions and hindering the simpler comparison
operations (with the overheads of flushing the pipeline after the
comparison). Intel has been shortening their CPU pipelines since the P-
IV, which would suggest the advantages might swing back to simple
comparison (though the machine I am sitting at right now has a P-IV
CPU).

See "The MegaHertz Myth" :
 
R

Richard Cornford

On Jun 30, 12:08 pm, Jorge wrote:
See "The MegaHertz Myth" :

I would appreciate it if you would not keep posting links to non-
functional/usable web pages. It severs no purpose and wastes my time
following them.

Richard.
 
J

Jorge

Richard said:
On Jun 30, 12:08 pm, Jorge wrote:


I would appreciate it if you would not keep posting links to non-
functional/usable web pages. It severs no purpose and wastes my time
following them.

Ohhh, that's truly pitiable. Please, excuse me.
 
R

RobG

No, don't.

I suppose that means you wish to write the article yourself, however
given the recent thread[1] where the in operator and isHostMethod were
discussed as alternatives, I'd request that you post it here first for
discussion. That thread is a very messy way for anyone to discover
the issues associated with detection of host features, I'm not sure
they'd come to a suitable conclusion from reading it.

What the FAQ item needs to convey is that it is practically impossible
to write a general "isObjectPropertyCallable" function to detect if a
method is callable or not (leaving out the use of try..catch as a
general solution). What is reasonable is to use typeof for native
methods, and to use isHostMethod for host methods that should be
callable and available if the UA supports certain W3C DOM
specifications. The isHostMethod as discussed in clj is not intended
to be used as a general tool to determine if any random object or
property name is callable.


1. <URL:
http://groups.google.com/group/comp...6?lnk=gst&q="is+host+method"#c66df69280fcdaf6
 
W

wilq

On Jun 30, 9:07 am, wilq wrote:


<snip>

The question of relative performance of regular expressions compared
with string comparison has come up before and on one occasion testing
revealed a significant factor that almost never seems to be considered
when people test the relative speeds' of things. I turned out that the
posted test-case (you have failed to post your test-case) showed
opposite results for different people running it.  Having verified
that the browser/JS environments were equivalent in each case interest
widened to the hardware environment, where it turned out that the CPU
appeared to be a significant factor, with P-III processors producing
the results where string comparison was fastest and P-IV processors
producing the results where regular expressions were fastest.

The (unproven) theory was that the P-IV's longer pipeline was
favouring the regular expressions and hindering the simpler comparison
operations (with the overheads of flushing the pipeline after the
comparison). Intel has been shortening their CPU pipelines since the P-
IV, which would suggest the advantages might swing back to simple
comparison (though the machine I am sitting at right now has a P-IV
CPU).

Richard.


I dont have access to mine profiling function so I create own one from
scratches. Its not great because I do this in hurry, if you have time
to test it - please do. If you have idea on what might interferee with
test cases - i'm open to hear :) Cheers:



// ************** CUT HERE *********************

// try to use small local scope

(function(){
// array of times and simple storing function
var times=[];
function addTime(){
times.push((new Date()).getTime());
}

// declaration of local variables - to make sure that we wont measure
creation of those variables
var someTemp;
var iterationCount=500000;
var i;
var a="function";
var b="object";
var regExp=/^function|object$/;

// start counting
addTime();

// for loop looks the same for both tests
for (i=0;i<iterationCount;i++)
{
// test simple string - first "object" then "function"
someTemp = regExp.test(a);
someTemp = regExp.test(b);
}
addTime();
for (i=0;i<iterationCount;i++)
{
// test simple string - first "object" then "function"
someTemp = (a==="function"||a==="object");
someTemp = (b==="function"||b==="object");
}
addTime();

// simple write output
document.write("Time for regexp: "+(times[1]-times[0])+"<br>");
document.write("Time for string comparsion: "+(times[2]-times[1]));
})();

// **************** CUT HERE ********************
 
W

wilq

On Jun 30, 9:07 am, wilq wrote:


<snip>

The question of relative performance of regular expressions compared
with string comparison has come up before and on one occasion testing
revealed a significant factor that almost never seems to be considered
when people test the relative speeds' of things. I turned out that the
posted test-case (you have failed to post your test-case) showed
opposite results for different people running it.  Having verified
that the browser/JS environments were equivalent in each case interest
widened to the hardware environment, where it turned out that the CPU
appeared to be a significant factor, with P-III processors producing
the results where string comparison was fastest and P-IV processors
producing the results where regular expressions were fastest.

The (unproven) theory was that the P-IV's longer pipeline was
favouring the regular expressions and hindering the simpler comparison
operations (with the overheads of flushing the pipeline after the
comparison). Intel has been shortening their CPU pipelines since the P-
IV, which would suggest the advantages might swing back to simple
comparison (though the machine I am sitting at right now has a P-IV
CPU).

Richard.

I dont have access to mine profiling function so I create own one
from
scratches. Its not great because I do this in hurry, if you have time
to test it - please do. If you have idea on what might interferee
with
test cases - i'm open to hear :) Cheers:
// ************** CUT HERE *********************



<html>
<body>
<script type="text/javascript">

(function(){
var times=[];
function addTime(){
times.push((new Date()).getTime());
}

var someTemp;
var iterationCount=500000;
var a="function";
var b="object";

var regExp=/^function|object$/;

function reg(){
for (var i=0;i<iterationCount;i++)
{
someTemp = regExp.test(a);
someTemp = regExp.test(b);
}}

function str(){
for (var i=0;i<iterationCount;i++)
{
someTemp = (a==="function"||a==="object");
someTemp = (b==="function"||b==="object");
}}

// UNCOMMENT THIS LINE TO profile IN FIREBUG
// console.profile("regExp vs string comp");

addTime();
reg();
addTime();
str();
addTime();

// UNCOMMENT THIS LINE TO profile IN FIREBUG
// console.profileEnd();

document.write("Time for regexp: "+(times[1]-times[0])+"<br>");
document.write("Time for string comparsion: "+(times[2]-times[1]));
})();

</script>
</body>
</html>
 
T

Thomas 'PointedEars' Lahn

wilq said:
I dont have access to mine profiling function so I create own one
from scratches. Its not great because I do this in hurry, if you have
time to test it - please do. If you have idea on what might interferee
with test cases - i'm open to hear :) Cheers:
[...]
(function(){
var times=[];
function addTime(){
times.push((new Date()).getTime());

Why, +new Date() suffices.
}

var someTemp;
var iterationCount=500000;

Several script engines might consider a script with that many iterations as
blocking, depending on accumulated runtime.
var a="function";
var b="object";

var regExp=/^function|object$/;

As written in e-mail, this will match either "function" at the start of
input, or "object" at the end of input (which I imagine to be slow), and
so is not equivalent to `either "function" or "object"'. You'll need

var regExp=/^(function|object)$/;

but, again, that does not consider leading or trailing whitespace.
function reg(){
for (var i=0;i<iterationCount;i++)
{
someTemp = regExp.test(a);
someTemp = regExp.test(b);

Cheater! :) Here both tests will be performed always (worst case), but that
is not necessary with /^\s*unknown\s*/i and /^\s*(object|function)\s*/i as
in `is(Host)Method'. Hence my reversing the order of tests since; shortcut
evaluation of boolean expressions will do the rest.
}}

function str(){
for (var i=0;i<iterationCount;i++)
{
someTemp = (a==="function"||a==="object");

Cheater! :) With your input, the second operand will never be evaluated,
and type conversion does not take place (best case).
someTemp = (b==="function"||b==="object");

With this approach, type conversion does not take place but might be
necessary with a `typeof' result when a host object is the operand. And
with your input, both operands will always be evaluated here (worst case).

When you have set up a test of roughly equivalent approaches we can talk
about the shortcomings of simple string comparison as compared to RegExp
matching. In particular when host objects and unknown input is involved.


PointedEars
 
W

wilq

wilq said:
I dont have access to mine profiling function so I create own one
from scratches. Its not great because I do this in hurry, if you have
time to test it - please do. If you have idea on what might interferee
with test cases - i'm open to hear :) Cheers:
[...]
(function(){
var times=[];
function addTime(){
  times.push((new Date()).getTime());

Why, +new Date() suffices.

If we use it every time when measuring - it is counted inside
measurement time for both operation (regexp and string)... so what
diffrence?
Several script engines might consider a script with that many iterations as
blocking, depending on accumulated runtime.

Yes of course - because of this is an argument that you can change.
As written in e-mail, this will match either "function" at the start of
input, or "object" at the end of input (which I imagine to be slow), and
so is not equivalent to `either "function" or "object"'.  You'll need

  var regExp=/^(function|object)$/;

but, again, that does not consider leading or trailing whitespace.


You can add those bracers to mine profiling function. As you probably
notice this does not change alot.
Cheater! :)  Here both tests will be performed always (worst case), butthat
is not necessary with /^\s*unknown\s*/i and /^\s*(object|function)\s*/i as
in `is(Host)Method'.  Hence my reversing the order of tests since; shortcut
evaluation of boolean expressions will do the rest.

Cheater ? I dont think so - I compare here cases that will occur
mostly - "function" and "object". But I do the same for string
solution so there is no cheat. In fact its very fair comparsion in
mine opinion. I open to see a best + worst case as you said that is in
string comparsion.
Cheater! :)  With your input, the second operand will never be evaluated,
and type conversion does not take place (best case).

Yes - this is a idea of this test. I propose this test as a answer to
post from some time ago that You were involved in:

Correct me if I'm wrong, you changed:

basically you changed there

(t=='function' || t=='object')

to:

/^(function|object)$/.test(t)


So here I also did the test. And in post before I explained why this
string comparsion would be better - exacly that if a first boolean
structure will be true, second wont be computed at all. You can try
diffrent cases (both worst, both good) with a="object", b="object" and
a="function", b="function" to see that this is still faster than
regexp...

With this approach, type conversion does not take place but might be
necessary with a `typeof' result when a host object is the operand.  And
with your input, both operands will always be evaluated here (worst case)..

If this is really so big diffrence for you ? Then please consider this
for the code that I gave:

var a=typeof (function(){});
var b=typeof ({someObject:0});

When you have set up a test of roughly equivalent approaches we can talk
about the shortcomings of simple string comparison as compared to RegExp
matching.  In particular when host objects and unknown input is involved.

PointedEars



Basically you pointed out some elements in code, but generally that
has nothing to do with really results of test. Also you did not
provide anything that would show that this approach is completly
wrong. Please then provide code that proves what you saying is true :)
I really like seeing things working than only talking. Then I can
judge your solution :)
 
D

dhtml

RobG said:
No, don't.

I suppose that means you wish to write the article yourself, however
given the recent thread[1] where the in operator and isHostMethod were
discussed as alternatives, I'd request that you post it here first for
discussion. That thread is a very messy way for anyone to discover
the issues associated with detection of host features, I'm not sure
they'd come to a suitable conclusion from reading it.

What the FAQ item needs to convey is that it is practically impossible
to write a general "isObjectPropertyCallable" function to detect if a
method is callable or not (leaving out the use of try..catch as a
general solution). What is reasonable is to use typeof for native
methods, and to use isHostMethod for host methods that should be
callable and available if the UA supports certain W3C DOM
specifications. The isHostMethod as discussed in clj is not intended
to be used as a general tool to determine if any random object or
property name is callable.

No, it is not a matter of wanting to write it myself.

Function isHostMethod is not a frequently asked question.

Arguments about isHostMethod function don't seem to be likely to
contribute suitable or appropriate material for the FAQ. It may very
lead to pedandtry, quibbling or even irrational zealotry and flames.

The code in that misnamed method pretends to imply that the property
is a method. I can't recommend that.

I am not incapable of writing, and do like help with the FAQ, but I am
busy with various things, including recent threads here (dynamic
loading), other things that are related to programming, and yet other
things in my life that are unrelated. Not sailboats, but good stuff
nonetheless.

Garrett
 
T

Thomas 'PointedEars' Lahn

kangax said:
Which clients produce leading and/or trailing white spaces around
"function" and/or "object" for typeof?

Those in unknown/not sufficiently tested runtime environments. After all,
`typeof' is specified to be implementation-dependent with host objects, and
it is impossible to test all host objects -- past, present, and future. If
you want to wait for the script to fail/break in favor of supposed greater
runtime efficiency instead, that is your decision.


PointedEars
 
T

Thomas 'PointedEars' Lahn

kangax said:
Thomas said:
The local version of object.js (0.1.5a.2009062116) currently features
jsx.object.isMethod() which allows to pass an object reference plus an
arbitrary number of string arguments. This allows e.g. isMethod(Array,
"prototype", "slice", "call") and avoids repeated calls of isMethod().

This sounds useful. Another common need is to test multiple methods on
the same base object, so these two (i.e. your n-level `isMethod` and
`areMethods`) might cover most of the use cases:

[...]
areMethods(document, 'body', ['appendChild', 'removeChild']);

Conceptionally, I like this approach best. Not much overloading and very
flexible. However, an Array object reference (which requires a reliable
Array test¹) should only be allowed as last argument to avoid expensive
backtracking; or do you have an idea for that as well?

¹ Regarding the cross-frame issue: what about a property referring
to the current Array object to be set and reset before/after call
as needed?
// compare to something like:

if (document &&
document.body &&
isMethod(document.body, 'appendChild') &&
isMethod(document.body, 'removeChild')) { ... }

`if (foo)' (here: foo === document) is not very reliable in any case,
though: Implicit type conversion on a host object (which may throw any
exception) using a property that may not even exist (which may throw a
TypeError). Therefore, I suggested allowing for the evaluation of primitive
strings that match /Identifier/ or property accessor for the first argument,
per flag so that methods of String objects could still be tested. What do
you think about that?


PointedEars
 
R

RobG

I suppose that means you wish to write the article yourself, [...]
What the FAQ item needs to convey is that it is practically impossible
to write a general "isObjectPropertyCallable" function to detect if a
method is callable or not (leaving out the use of try..catch as a
general solution). What is reasonable is to use typeof for native
methods, and to use isHostMethod for host methods that should be
callable and available if the UA supports certain W3C DOM
specifications. The isHostMethod as discussed in clj is not intended
to be used as a general tool to determine if any random object or
property name is callable.


No, it is not a matter of wanting to write it myself.

Function isHostMethod is not a frequently asked question.

A search in GG for "isHostMethod" returns over 230 responses, the
first in February 2008. I think that qualifies at least as a frequent
topic. I don't think an FAQ is necessarily based on actual questions
being asked, but rather frequent answers that are, or are expected to
be, given. When was the last time someone asked "Why are my rollovers
so slow?".

No one has posted to this thread to say there is no need for the item,
it represents a step forward in feature detection of host methods and
the topic has come up a number of times recently. That is sufficient
to prompt consideration for inclusion in the FAQ - so that it can be
referenced and provide a definitive statement about the topic.

Arguments about isHostMethod function don't seem to be likely to
contribute suitable or appropriate material for the FAQ. It may very
lead to pedandtry, quibbling or even irrational zealotry and flames.

It takes a draft FAQ item for that? ;-)

The only minor quibble I see here is over whether a regular expression
should be used or not - that is a relatively trivial matter related to
performance, not the purpose or overall design. I know you have a
personal opinion that the in operator should be used, but that is a
minority view.

The code in that misnamed method pretends to imply that the property
is a method. I can't recommend that.

That is your opinion, and while you may be the FAQ maintainer, that
does not make you sole arbiter of what it should or should not
contain. The purpose and limitations of the function have been
expressed (and summarised previously in this thread), they should be
part of the entry.

I am not incapable of writing, and do like help with the FAQ, but I am
busy with various things, including recent threads here (dynamic
loading), other things that are related to programming, and yet other
things in my life that are unrelated. Not sailboats, but good stuff
nonetheless.


There is no need for you to participate in the discussion, there are
half a dozen regulars who have already done so since the topic was
first raised. It only requires someone to post a draft, discussion to
occur, and suitable agreement be reached. It is then up to the FAQ
maintainer to put it in the FAQ.
 
P

Peter Michaux

I guess you mean this one:

Feature Detection: State of the Art Browser Scripting
<URL:http://peter.michaux.ca/articles/feature-detection-state-of-the-art-b...

I don't know how easy it would be to summarize the isHostMethod,
isHostCollection, and isHostObject functions down to a reasonably
sized FAQ entry. It is worth a try if there is consensus about which
functions to include.

It is not trivially clear cut which of the three functions to use at
any particular time. Some host properties fall into all three
categories. For example, document.all is a collection, function and
object.

These three functions depend on non-standardized behavior of the
typeof operator. The typeof operator is being used as some sort of
magic try-catch but the ECMAScript standard doesn't say anything about
that behavior. From my reading of the standard if obj.prop blows up in
some browser than so could typeof(obj.prop). It just so happens that
the implementations don't blow up when using the typeof version.

It has been so long since I really thought about this topic. I
remember that there was one function that could replace all three
isHost* functions at increased risk of false positives but with no
known false positives in existence. I still wonder if the three
isHost* functions are overly paranoid and the riskier one function is
sufficient.

Peter
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top