D
David Mark
http://github.com/yui/yui3/commit/a3b173f97e351148a2741470a46c87e93424c16d#diff-0
1076 1076
1077 1077 hasMethod: function(method) {
1078 1078 var node = this._node;
1079 - return !!(node && method in node && node[method].apply);
1079 + return !!(node && method in node &&
1080 + (typeof node[method] === 'function' ||
1081 + String(node[method]).indexOf('function') ===
1)); // IE reports as object, prepends space
Passing a host object method to the String constructor. Are they
completely insane? One thing is for sure, they don't read this group
(or peruse my site).
http://www.cinsoft.net/host.html
" kangax added a note to a3b173f build/node/node-base-debug.js:L1081
May 14, 2010
String-converting host objects is known to blow up in IE, so this is not
a very good idea. Function decompilation is another thing that's best
avoided."
Good man.
" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081
May 15, 2010
Its not pretty, but it works in IE6 and isn't blowing up any test cases."
It most assuredly does _not_ work in IE6 (or any version of IE for that
matter). This is what happens when you program by observation. He's
looking for a failure case, instead of understanding the abstraction
which says: host objects can do whatever the hell they want. It's been
well-established (for about ten years) that typeof is the only safe way
to detect their methods. It's been written up here a thousand times.
Who on the planet that writes JS for a living hasn't heard of isHostMethod?
"Let me know if you have a failure case."
There it is. Show me where it fails. That's what the Dojo people say
over and over. If a lack of a failure case is your only justification
for your logic, then you don't understand cross-browser scripting at
all. Do these people ever think about what will happen tomorrow? The
whole point of things like YUI and Dojo is that they are supposedly
needed due to the ever-changing browsers, yet their authors will commit
anything that appears to work in _today's_ browsers (well, the four or
five they profess to "care" about). They don't seem to understand that
tomorrow's browsers may change. What sort of logic is that? And it's
not like they don't have an avalanche of broken browsers behind them to
serve as reminders. All I can figure is that they are all suffering
from mass hysteria and the developers who lean on them have just gotten
used to the endless failures. You sure don't have to show them where it
fails.
"Better yet, suggest a cleaner hasMethod test."
Why bother? I know what will come of it. I suggested a cleaner Dojo.
Lots of similar blithering ensued and it never got used.
"This undocumented method will likely be marked deprecated in a future
release."
Great.
" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081
5 days ago
Based on the change, you seem to have realized that host objects aren't
functions and don't have an apply method. Most realized that 5 years ago
or more. Where have you been?"
They've been working on YUI of course. Just gettin' stuff done in the
Real World (where host methods work like native functions and IE never
throws exception on type conversions).
"Converting host property object to string and parsing the string to see
what it looks like doesn't really provide indication for the capability
of that property.
when node is a form:
hasMethod("item")
And yes, string conversion of host object is known to blow up in IE,
even [[Get]] can cause unknown error. The in operator may provide
misleading results with catchall. For most consistent results, use typeof."
As hopefully any novice knows by now.
" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081
5 days ago
Thanks for the feedback."
I find that open source contributors usually go out of their way to be
polite. It's often all they've got. And it gives them an excuse to
dismiss criticism as rude by comparison (they want to get back to having
fun again).
"If you're assertion is true ("For most consistent results, use typeof")
then you have nothing to worry about as IE should never reach the OR
condition that converts to string."
Oh brother. If? And, once again, today's observations alone are enough
to go by (until tomorrow of course). Don't attempt to understand
anything, just watch the browsers and adjust to suit. Of course, in
this case, the observations are demonstrably faulty _today_ (as well as
ten years ago). And this is a "major" library with tons of widgets
stacked on top of it, published by a behemoth enterprise (Yahoo!)
"Unfortunately, that is consistently wrong, as typeof on a host object
in IE is "object"."
That's not "wrong". What is wrong is the design of the "soon to be
deprecated" function. Welcome to 2001, er 2010.
"As mentioned, this undocumented method will be likely be deprecated."
So no need to fix it or learn anything from its failings.
"However, I would love to be enlightened by those in the "know", so
please submit a use-case that makes YUI::Node:hasMethod blow up."
Show me where it fails. Show me where it fails. Show me where it
fails. Ugh. Even if it doesn't fail today, it may well fail tomorrow.
See all of those broken "degraded" browsers behind you? Best to
finally learn what you are doing.
And note the snide attempt at irony. That's typical. The more ignorant
they are, the quicker they resort to baiting. IIRC, Resig launched into
similar snipes almost instantly when I first reviewed his garbage (and
slowly but surely implemented most of the ideas I fed him).
" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081
5 days ago
The typeof operator takes an operand and results in string; it is not
consistently wrong. typeof on a host object in IE is not consistently
"object". Try the example I provided in my last message. Again:
when node is a form:
hasMethod("item")
A program expecting MSIE to consistently result "object" for methods
will fail if the type is something other than object. The typeof
operator returns implementation dependent string for host object in ES3.
But carry on as you like."
And you know they will.
" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081
5 days ago
Thanks Garrett."
"The example you provide is exactly why this method is currently
undocumented, and why it will likely be deprecated."
That's three times now.
"Short of try/catching a call to the method, I haven't found a reliable
way to determine whether the object is a function or not in all cases."
OMG. I can repeat myself too.
http://www.cinsoft.net/host.html
i - s - H - o - s - t - M - e - t - h - o - d. There you go.
"Unfortunately, in my testing, no native dom node reports anything as
typeof "function", so all checks fall to the String coercion."
http://www.cinsoft.net/host.html
i - s - H - o - s - t - M - e - t - h - o - d. There you go.
"The only assumptions made here are that calling the String constructor
on native dom properties/methods is safe."
Native dom properties/methods? Regardless, that's not a safe assumption.
http://www.cinsoft.net/host.html
i - s - H - o - s - t - M - e - t - h - o - d. There you go.
"I've heard anecdotally that this may "blow up" in some cases, however
none of these case have surfaced with this implementation. A testcase to
the contrary would be helpful."
Show me where it fails. Show me where it fails...
"Rather than commenting on checkins, a better way to contribute would be
to help solve this problem."
And commenting on check-ins is not a way to help solve the problem?
"While I'm not convinced Node::hasMethod belongs in the library,
Y.Lang.isFunction could benefit with some help here."
Well, make up your mind. Do you want more comments or not?
" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081
5 days ago
Anything where typeof results in "unknown".
Here:
typeof document.createElement("xml").onreadystatechange; // "unknown"
document.createElement("xml").onreadystatechange; // boom!"
Yes, that's a classic.
"The ES3 specification states that for host object, the result of typeof
is implementation-dependent. Notable changes are seen between Opera
versions and IE. Moreover, string conversion of host objects, as stated,
is not required by ES3 and that can blow up, too."
That's an abstraction put forth by the specification. Understand that
and you will understand why "isFunction" has no place in a JS program
and "hasMethod" won't work for any arbitrary property you throw at it.
There has to be a contract between the caller and the function, which
should be documented. Here it is:-
http://www.cinsoft.net/mylib-doc.asp#ishostmethod
"Using the value of string converting a host object to determine program
decisions is ridiculous. No standard requires string conversion of host
object. The result is nonstandard, proprietary, undocumented. You should
not be doing that."
Exactly. Understand that and you never have to test this in another
browser again. I haven't since around 2001. And not one explosion since.
"For example, in IE, I can see the string value of alert, which is a
host method, has "function" in it.
javascript: alert( String( alert ) )
My suggestion for helping out with isFunction is to refactor anything
that uses it to not do that, to deprecate isFunction, and to remove it.
It is broken by design."
I suspect you are spitting in the wind. That's almost exactly what I
told the Dojo people about isFunction and isArray. They still exist to
this day and are called by about a thousand different functions. New
functions are constantly added that must discriminate between host
objects, arrays and Object objects (a trifecta!) It's almost as if they
go out of their way to run straight into the walls imposed by the
language. I wonder if anyone working on these "standard" libraries that
support so many shiny widgets (which unsurprisingly break down, even in
the handful of "current" browsers they ostensibly support) knows the
first thing about any of this. I couldn't vouch for them. Not a one.
"/**
* Determines whether or not the provided object is a function.
* Note: Internet Explorer thinks certain functions are objects:
*/
The comment further indicates that the author believes that getAttribute
is a function in IE. There is no reason for believing that to be true
and in fact it is false."
I remember Resig blogged about it being called without a call operator
at one point. Of course, he was wrong and blaming his failure to
understand on voodoo.
"Y.Lang.isFunction does not and can not, in the general sense, fulfill
what is promised in its preceding code comment."
Of course not. It should not be allowed to accept host objects of any
sort (not even methods). And if it can't accept host objects, what do
you need it for? Okay, the odd native object that is callable in some
browsers but not others (e.g. RegExp). So disallow passing those
objects as well. Once you understand that, you don't design
"overloaded" functions that must discriminate between regular
expressions and functions. End of story.
typeof xyz == 'function'; // What else do you need?
"It fails due to the reasons that been discussed over the years on
c.l.js and touched upon here. It boils down to typeof having different
results with host object and the [[Class]] property being
implementation-dependent for host object. It fails for other reasons
where a built-in may have also a [[Call]] property, or be somehow
callable without having a [[Call]] property (as spidermonkey RegExp)."
Right. Though I don't know about any Spidermonkey object that is
callable but does not implement [[Call]] internally. How do you figure
that? Regardless, this is all well beyond what the YUI authors can (or
need to) digest.
"The function is a failed attempt because the author demonstrates
misleading information about the a callable object being a function. An
object that is callable is not necessarily a function. Failing to make
that distinction in a code comment, and, moreover, providing a false
statement with getAttribute, shows that the author does not know that
the function is not clear on what can be expected of it.
As such, use of that function should be avoided."
As should the author.
"More details of "isFunction" functions, typeof, and host methods have
been discussed over the years on c.l.js."
" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081 "
I can't say as I'm optimistic. I really don't want to read it, but...
"4 days ago
The "boom" in your test is a "not supported" JS error due to
node[method] access on a field of type "unknown", not String conversion."
Here we go. Any type conversion will do it. Try it!
"Treating "unknown" as "undefined" resolves this issue and puts the
hasMethod result inline with other vendor implementations for the
xmlNode.hasMethod('onreadystatechange') test case."
Not even close.
"As I mentioned, while not sold on the Node::hasMethod, we are
interested in beefing up support for Lang::isFunction."
Did you not read the previous comments? It doesn't need "beefing up"
but slaughtering.
"This discussion would be more appropriate on YUI Forums or within our
ticket system."
I suspect it would be just as productive in those venues.
" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081
4 days ago
You wrote: "Treating "unknown" as "undefined" resolves this issue and
puts the hasMethod result inline with other vendor implementations "
That is completely wrong and false. The unknown type represents ActiveX
object.
Didn't you just publish a chapter in book? And you're on the YUI team....
Unbelievable."
Indeed. What book would that be? And being on the YUI team is not
exactly a badge of honor. More of a scarlet letter (Y).
" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081 "
I know I don't want to continue, but it's like watching a train wreck...
"4 days ago
Thanks Garrett."
"Calling Node::hasMethod against your xml test case is now "false", as
expected."
Oh God. Expected by whom?
"Please file a bug for any failing case you have with this
implementation. Calling it "wrong" doesn't get any closer to a resolution."
Show me where it fails; show me where if fails; show me, show me, show
me... Arrgh!! Not even an attempt at understanding. None of the
previous registered at all? It's like what one of the Dojo team members
told me: I'm not too good with abstractions. How can you write software
if you aren't "too good" with abstractions? Well, badly of course (and
Dojo is certainly bad).
" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081
4 days ago
Quote: "Calling Node::hasMethod against your xml test case is now
"false", as expected."
No, and for example, a true result for:-
typeof hostObject.property === "unknown"
- is not an indication that the property is undefined; quite the
contrary. In IE, some host objects are implemented as ActiveX objects.
When an ActiveX object is supplied to typeof operator, the result is
"unknown"."
When a _property_ of an ActiveX object... We went over this.
"And so the example typeof hostObject.property === "unknown" would be
indicative that the property is an ActiveX object."
Yes, it is a specific type of ActiveX object that is only found in
JScript implementations as a _property_ of other types of ActiveX
objects (which do not have "unknown" types themselves).
"This matches behavior documented in MS-ES3, for SafeArray."
That's the one.
"MSDN links are broken, but a copy of MS-ES3 may be found on the FAQ:
http://jibbering.com/faq/#resources"
That was four days ago. The line seems to have gone dead. Hopefully
YUI will follow suit. As it is full of UA sniffing, I'm sure it will.
It's not like it is setting the world at present.
If that all sounds harsh, realize that I have to deal with these things
constantly. I don't mind as I get paid dearly for it. But I feel for
the clients. YUI, Dojo, etc. projects shouldn't require a high-end JS
consultant on permanent standby. Aren't they supposed to make things
_easier_, saving tine and money? I know for sure it doesn't pan out
(except for me). These things are gold. If I were selfish, I wouldn't
say a word, would I? Think about that before whining about my criticism(s).
1076 1076
1077 1077 hasMethod: function(method) {
1078 1078 var node = this._node;
1079 - return !!(node && method in node && node[method].apply);
1079 + return !!(node && method in node &&
1080 + (typeof node[method] === 'function' ||
1081 + String(node[method]).indexOf('function') ===
1)); // IE reports as object, prepends space
Passing a host object method to the String constructor. Are they
completely insane? One thing is for sure, they don't read this group
(or peruse my site).
http://www.cinsoft.net/host.html
" kangax added a note to a3b173f build/node/node-base-debug.js:L1081
May 14, 2010
String-converting host objects is known to blow up in IE, so this is not
a very good idea. Function decompilation is another thing that's best
avoided."
Good man.
" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081
May 15, 2010
Its not pretty, but it works in IE6 and isn't blowing up any test cases."
It most assuredly does _not_ work in IE6 (or any version of IE for that
matter). This is what happens when you program by observation. He's
looking for a failure case, instead of understanding the abstraction
which says: host objects can do whatever the hell they want. It's been
well-established (for about ten years) that typeof is the only safe way
to detect their methods. It's been written up here a thousand times.
Who on the planet that writes JS for a living hasn't heard of isHostMethod?
"Let me know if you have a failure case."
There it is. Show me where it fails. That's what the Dojo people say
over and over. If a lack of a failure case is your only justification
for your logic, then you don't understand cross-browser scripting at
all. Do these people ever think about what will happen tomorrow? The
whole point of things like YUI and Dojo is that they are supposedly
needed due to the ever-changing browsers, yet their authors will commit
anything that appears to work in _today's_ browsers (well, the four or
five they profess to "care" about). They don't seem to understand that
tomorrow's browsers may change. What sort of logic is that? And it's
not like they don't have an avalanche of broken browsers behind them to
serve as reminders. All I can figure is that they are all suffering
from mass hysteria and the developers who lean on them have just gotten
used to the endless failures. You sure don't have to show them where it
fails.
"Better yet, suggest a cleaner hasMethod test."
Why bother? I know what will come of it. I suggested a cleaner Dojo.
Lots of similar blithering ensued and it never got used.
"This undocumented method will likely be marked deprecated in a future
release."
Great.
" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081
5 days ago
Based on the change, you seem to have realized that host objects aren't
functions and don't have an apply method. Most realized that 5 years ago
or more. Where have you been?"
They've been working on YUI of course. Just gettin' stuff done in the
Real World (where host methods work like native functions and IE never
throws exception on type conversions).
"Converting host property object to string and parsing the string to see
what it looks like doesn't really provide indication for the capability
of that property.
when node is a form:
hasMethod("item")
And yes, string conversion of host object is known to blow up in IE,
even [[Get]] can cause unknown error. The in operator may provide
misleading results with catchall. For most consistent results, use typeof."
As hopefully any novice knows by now.
" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081
5 days ago
Thanks for the feedback."
I find that open source contributors usually go out of their way to be
polite. It's often all they've got. And it gives them an excuse to
dismiss criticism as rude by comparison (they want to get back to having
fun again).
"If you're assertion is true ("For most consistent results, use typeof")
then you have nothing to worry about as IE should never reach the OR
condition that converts to string."
Oh brother. If? And, once again, today's observations alone are enough
to go by (until tomorrow of course). Don't attempt to understand
anything, just watch the browsers and adjust to suit. Of course, in
this case, the observations are demonstrably faulty _today_ (as well as
ten years ago). And this is a "major" library with tons of widgets
stacked on top of it, published by a behemoth enterprise (Yahoo!)
"Unfortunately, that is consistently wrong, as typeof on a host object
in IE is "object"."
That's not "wrong". What is wrong is the design of the "soon to be
deprecated" function. Welcome to 2001, er 2010.
"As mentioned, this undocumented method will be likely be deprecated."
So no need to fix it or learn anything from its failings.
"However, I would love to be enlightened by those in the "know", so
please submit a use-case that makes YUI::Node:hasMethod blow up."
Show me where it fails. Show me where it fails. Show me where it
fails. Ugh. Even if it doesn't fail today, it may well fail tomorrow.
See all of those broken "degraded" browsers behind you? Best to
finally learn what you are doing.
And note the snide attempt at irony. That's typical. The more ignorant
they are, the quicker they resort to baiting. IIRC, Resig launched into
similar snipes almost instantly when I first reviewed his garbage (and
slowly but surely implemented most of the ideas I fed him).
" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081
5 days ago
The typeof operator takes an operand and results in string; it is not
consistently wrong. typeof on a host object in IE is not consistently
"object". Try the example I provided in my last message. Again:
when node is a form:
hasMethod("item")
A program expecting MSIE to consistently result "object" for methods
will fail if the type is something other than object. The typeof
operator returns implementation dependent string for host object in ES3.
But carry on as you like."
And you know they will.
" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081
5 days ago
Thanks Garrett."
"The example you provide is exactly why this method is currently
undocumented, and why it will likely be deprecated."
That's three times now.
"Short of try/catching a call to the method, I haven't found a reliable
way to determine whether the object is a function or not in all cases."
OMG. I can repeat myself too.
http://www.cinsoft.net/host.html
i - s - H - o - s - t - M - e - t - h - o - d. There you go.
"Unfortunately, in my testing, no native dom node reports anything as
typeof "function", so all checks fall to the String coercion."
http://www.cinsoft.net/host.html
i - s - H - o - s - t - M - e - t - h - o - d. There you go.
"The only assumptions made here are that calling the String constructor
on native dom properties/methods is safe."
Native dom properties/methods? Regardless, that's not a safe assumption.
http://www.cinsoft.net/host.html
i - s - H - o - s - t - M - e - t - h - o - d. There you go.
"I've heard anecdotally that this may "blow up" in some cases, however
none of these case have surfaced with this implementation. A testcase to
the contrary would be helpful."
Show me where it fails. Show me where it fails...
"Rather than commenting on checkins, a better way to contribute would be
to help solve this problem."
And commenting on check-ins is not a way to help solve the problem?
"While I'm not convinced Node::hasMethod belongs in the library,
Y.Lang.isFunction could benefit with some help here."
Well, make up your mind. Do you want more comments or not?
" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081
5 days ago
Anything where typeof results in "unknown".
Here:
typeof document.createElement("xml").onreadystatechange; // "unknown"
document.createElement("xml").onreadystatechange; // boom!"
Yes, that's a classic.
"The ES3 specification states that for host object, the result of typeof
is implementation-dependent. Notable changes are seen between Opera
versions and IE. Moreover, string conversion of host objects, as stated,
is not required by ES3 and that can blow up, too."
That's an abstraction put forth by the specification. Understand that
and you will understand why "isFunction" has no place in a JS program
and "hasMethod" won't work for any arbitrary property you throw at it.
There has to be a contract between the caller and the function, which
should be documented. Here it is:-
http://www.cinsoft.net/mylib-doc.asp#ishostmethod
"Using the value of string converting a host object to determine program
decisions is ridiculous. No standard requires string conversion of host
object. The result is nonstandard, proprietary, undocumented. You should
not be doing that."
Exactly. Understand that and you never have to test this in another
browser again. I haven't since around 2001. And not one explosion since.
"For example, in IE, I can see the string value of alert, which is a
host method, has "function" in it.
javascript: alert( String( alert ) )
My suggestion for helping out with isFunction is to refactor anything
that uses it to not do that, to deprecate isFunction, and to remove it.
It is broken by design."
I suspect you are spitting in the wind. That's almost exactly what I
told the Dojo people about isFunction and isArray. They still exist to
this day and are called by about a thousand different functions. New
functions are constantly added that must discriminate between host
objects, arrays and Object objects (a trifecta!) It's almost as if they
go out of their way to run straight into the walls imposed by the
language. I wonder if anyone working on these "standard" libraries that
support so many shiny widgets (which unsurprisingly break down, even in
the handful of "current" browsers they ostensibly support) knows the
first thing about any of this. I couldn't vouch for them. Not a one.
"/**
* Determines whether or not the provided object is a function.
* Note: Internet Explorer thinks certain functions are objects:
*/
The comment further indicates that the author believes that getAttribute
is a function in IE. There is no reason for believing that to be true
and in fact it is false."
I remember Resig blogged about it being called without a call operator
at one point. Of course, he was wrong and blaming his failure to
understand on voodoo.
"Y.Lang.isFunction does not and can not, in the general sense, fulfill
what is promised in its preceding code comment."
Of course not. It should not be allowed to accept host objects of any
sort (not even methods). And if it can't accept host objects, what do
you need it for? Okay, the odd native object that is callable in some
browsers but not others (e.g. RegExp). So disallow passing those
objects as well. Once you understand that, you don't design
"overloaded" functions that must discriminate between regular
expressions and functions. End of story.
typeof xyz == 'function'; // What else do you need?
"It fails due to the reasons that been discussed over the years on
c.l.js and touched upon here. It boils down to typeof having different
results with host object and the [[Class]] property being
implementation-dependent for host object. It fails for other reasons
where a built-in may have also a [[Call]] property, or be somehow
callable without having a [[Call]] property (as spidermonkey RegExp)."
Right. Though I don't know about any Spidermonkey object that is
callable but does not implement [[Call]] internally. How do you figure
that? Regardless, this is all well beyond what the YUI authors can (or
need to) digest.
"The function is a failed attempt because the author demonstrates
misleading information about the a callable object being a function. An
object that is callable is not necessarily a function. Failing to make
that distinction in a code comment, and, moreover, providing a false
statement with getAttribute, shows that the author does not know that
the function is not clear on what can be expected of it.
As such, use of that function should be avoided."
As should the author.
"More details of "isFunction" functions, typeof, and host methods have
been discussed over the years on c.l.js."
" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081 "
I can't say as I'm optimistic. I really don't want to read it, but...
"4 days ago
The "boom" in your test is a "not supported" JS error due to
node[method] access on a field of type "unknown", not String conversion."
Here we go. Any type conversion will do it. Try it!
"Treating "unknown" as "undefined" resolves this issue and puts the
hasMethod result inline with other vendor implementations for the
xmlNode.hasMethod('onreadystatechange') test case."
Not even close.
"As I mentioned, while not sold on the Node::hasMethod, we are
interested in beefing up support for Lang::isFunction."
Did you not read the previous comments? It doesn't need "beefing up"
but slaughtering.
"This discussion would be more appropriate on YUI Forums or within our
ticket system."
I suspect it would be just as productive in those venues.
" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081
4 days ago
You wrote: "Treating "unknown" as "undefined" resolves this issue and
puts the hasMethod result inline with other vendor implementations "
That is completely wrong and false. The unknown type represents ActiveX
object.
Didn't you just publish a chapter in book? And you're on the YUI team....
Unbelievable."
Indeed. What book would that be? And being on the YUI team is not
exactly a badge of honor. More of a scarlet letter (Y).
" msweeney added a note to a3b173f build/node/node-base-debug.js:L1081 "
I know I don't want to continue, but it's like watching a train wreck...
"4 days ago
Thanks Garrett."
"Calling Node::hasMethod against your xml test case is now "false", as
expected."
Oh God. Expected by whom?
"Please file a bug for any failing case you have with this
implementation. Calling it "wrong" doesn't get any closer to a resolution."
Show me where it fails; show me where if fails; show me, show me, show
me... Arrgh!! Not even an attempt at understanding. None of the
previous registered at all? It's like what one of the Dojo team members
told me: I'm not too good with abstractions. How can you write software
if you aren't "too good" with abstractions? Well, badly of course (and
Dojo is certainly bad).
" GarrettS added a note to a3b173f build/node/node-base-debug.js:L1081
4 days ago
Quote: "Calling Node::hasMethod against your xml test case is now
"false", as expected."
No, and for example, a true result for:-
typeof hostObject.property === "unknown"
- is not an indication that the property is undefined; quite the
contrary. In IE, some host objects are implemented as ActiveX objects.
When an ActiveX object is supplied to typeof operator, the result is
"unknown"."
When a _property_ of an ActiveX object... We went over this.
"And so the example typeof hostObject.property === "unknown" would be
indicative that the property is an ActiveX object."
Yes, it is a specific type of ActiveX object that is only found in
JScript implementations as a _property_ of other types of ActiveX
objects (which do not have "unknown" types themselves).
"This matches behavior documented in MS-ES3, for SafeArray."
That's the one.
"MSDN links are broken, but a copy of MS-ES3 may be found on the FAQ:
http://jibbering.com/faq/#resources"
That was four days ago. The line seems to have gone dead. Hopefully
YUI will follow suit. As it is full of UA sniffing, I'm sure it will.
It's not like it is setting the world at present.
If that all sounds harsh, realize that I have to deal with these things
constantly. I don't mind as I get paid dearly for it. But I feel for
the clients. YUI, Dojo, etc. projects shouldn't require a high-end JS
consultant on permanent standby. Aren't they supposed to make things
_easier_, saving tine and money? I know for sure it doesn't pan out
(except for me). These things are gold. If I were selfish, I wouldn't
say a word, would I? Think about that before whining about my criticism(s).