YUI--doomed?
in [JavaScript]
|
Prev: Acheter ACEON pilule enligne
Next: keyboard commands?
From: David Mark on 22 May 2010 18:11 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).
From: "Michael Haufe ("TNO")" on 23 May 2010 01:02 On May 22, 5:11 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > [...] I'm curious to why you bother. The subjects of your criticism don't understand the language in theory yet are trying to put it into practice and also show no willingness to improve on that situation. Why not just let them collapse in upon themselves if that is what they are destined to do anyway as you've claimed?
From: Andrew Poulos on 23 May 2010 02:10 On 23/05/2010 3:02 PM, Michael Haufe ("TNO") wrote: > On May 22, 5:11 pm, David Mark<dmark.cins...(a)gmail.com> wrote: >> [...] > > I'm curious to why you bother. The subjects of your criticism don't > understand the language in theory yet are trying to put it into > practice and also show no willingness to improve on that situation. > Why not just let them collapse in upon themselves if that is what they > are destined to do anyway as you've claimed? I'd say that because they bank on the name of "Yahoo" they'll drag a bunch of other people, who aren't in a position to judge the quality of the code, down with them. Andrew Poulos
From: David Mark on 23 May 2010 05:45 Michael Haufe ("TNO") wrote: > On May 22, 5:11 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >> [...] > > I'm curious to why you bother. Why does anyone bother to do anything? At least I am trying to bring about positive change. And it has worked well (if sporadically) over the years. Somebody from YUI will see this and you can bet they will get the message eventually. In the interim, I predict there will be a lot of hissing and moaning on IRC, the term "troll" will be bandied about (ironic for IRC dwellers who live below the newsgroups) and perhaps a new article will be posted to StackOverflow (or the like); not to address the issues, but to question my motivations. But notice how jQuery finally removed the UA sniffing, despite Resig's obvious misunderstandings about it. Remember his reaction when I first told him he was screwing up (and about ten years behind the times). This was in 2007. It finally sunk in (about a year later). The attribute issues were discussed in that same thread, but they are still chewing on those. In 2010. Just for the record, the issues in question date back to 1999 (and were never a secret). Granted, I didn't publish a GP solution (with appropriate feature testing) until 2007. Same for other feature testing tidbits that eventually showed up in jQuery, Prototype and countless other small projects. The larger dinosaurs (e.g. Dojo, YUI) are slower to move. Their brains are too far removed from their tails. ;) http://www.cinsoft.net/host.html Like tossing a boulder into the ocean, eventually the waves break on every shore. > The subjects of your criticism don't > understand the language in theory yet are trying to put it into > practice and also show no willingness to improve on that situation. Yes, so one of my motivations is to *warn* developers to steer clear of projects like that. You don't think there is a *huge* problem with naive developers being taken in by projects like this? I do as I see it every day. They end up buying books, T-shirts, attending fanboy conferences and never seem to realize that they've been had. It sucks a fortune out of the economy (a portion of which ends up in my pocket eventually, so I can hardly be criticized for speaking up about the problem). In short, if you are developing with YUI, Dojo, etc. and don't have a clue what goes on in inside it, you best have someone like me on site (or on a short leash). Because when things break, the only recourse is to upgrade/downgrade pieces (or all) of the canned software and/or ask the authors of the software (as seen in the OP) what they think. And as we've seen endlessly, the developers don't know anything. ;) On the contrary, reading their source is like reading a coloring book for me. A very bad, ugly coloring book with gaudy color, drawing outside the lines, etc. > Why not just let them collapse in upon themselves if that is what they > are destined to do anyway as you've claimed? So I should just clam up and let them take everyone else with them. Apathy is just not my thing. And the "collapse" won't be complete as there will always be dead-enders slaving away at these things. Dojo never even bubbled, so there's nothing to collapse, yet that doesn't deter its authors (who are hopelessly deluded and blind to their own failings). Whet is happening should be obvious. iPhones/iPads are a prime example of how Joe Consumer is starting to rely less and less on Joe Web Developer. Who wants to deal with flaky scripts in a browser when you can buy shiny applications from Apple's store? The Web will not be the application platform of the future; that much is clear at this point. Such proprietary platforms are to the Web as the Web was to the old bulletin board systems. The incompetents have thrown the game away by concentrating on follies like CSS selector queries (five years down the drain), bloated OO architecture that bastardizes the language, crappy grid widgets, etc. It's all been a huge waste. The Web will never be Windows. And Dojo, YUI, etc. will never be Visual Basic.
From: David Mark on 23 May 2010 06:27
David Mark wrote: [...] > > 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. > That was supposed to read "setting the world ablaze". They do make lots of videos of themselves talking about it though. What a colossal waste. :( |