Error-free deep property access?
in [JavaScript]
|
Prev: FAQ Topic - How can I access the client-side filesystem? (2010-05-11)
Next: apparently wrong function.
From: Garrett Smith on 12 May 2010 19:00 Stefan Weiss wrote: > On 12/05/10 21:57, Garrett Smith wrote: >> Stefan Weiss wrote: >>> On 11/05/10 15:44, Matt Kruse wrote: >>>> Does anyone here use a general convenience method for deep property >> [...] >> >>> This may be obvious, but did you consider simply catching and ignoring >>> the ReferenceError? >>> >>> try { var color = body.firstChild.style.backgroundColor; } catch(e) {} >>> >>> Maybe it doesn't look as nice as your deep() call, but at least there's >>> no custom syntax involved, and you can use arbitrary property names, >>> including all the counter examples mentioned by Thomas, and even >>> expressions like childNodes[i+1]. >> Starting a statement that way isn't "not as nice" it is a failure of the >> code to express its intent. The try statement misleads the reader. Why >> is it there? Can anyone know? > > Anyone who knows what the code they're reading is supposed to do should > have a pretty good idea. I agree that it's not pretty, but it becomes > more obvious if you write it like this: > > try { > var color = body.firstChild.style.backgroundColor; > } catch (e) { > color = someDefaultValue; > } > What the code tries to do is apparent; why it needs to try is not. Was body.firstChild throwing errors? Which errors? And which browsers? A reason for adding try catch is to handle an error that the code does not have control over. It might be a host object related issue or it could be that the caller passed in a function, where calling that function may result in an error that could be handled by the program, rather than terminating it. In this case, the only known error was caused by the code itself, and so not doing that would seem like a much more obvious choice. The other thing I don't like about that construct is that the color variable is declared inside the try. We know it is is going to be hoisted to the VO and used either there. var color; try { var color = body.firstChild.style.backgroundColor; } catch (e) { color = someDefaultValue; } If the try catch were really justified, and it isn't, it could be moved to a separate function making the code a lot easier to understand as: var color = getColor(); > I don't think I'd need any additional explanations when I read this, > except in unusual situations, and those should always be commented. > Anyway, you can always write > > if (body > && body.firstChild > && body.firstChild.style > && body.firstChild.style.backgroundColor) > { Plain as day. > var color = body.firstChild.style.backgroundColor; > } else { > color = someDefaultValue; > } > > if you think that's more readable. To each their own. > Property existence checks like that are self documenting. Try catch is not. There is no obvious reason why the try catch is there, only. It appears to be used to catch an error but what sort of error? Who can know, but looking at the code? Not including the author. [...] >> Someone may also mention that using try/catch is inefficient, and it is, >> but that is the least of the problems. > > Especially when you're afraid to use it because you think it *might* be > slower than a function like $prop, but don't bother testing it first. > > In Firefox 3.0, try/catch is 3-4 times faster than $prop, in IE 6 and IE > 7 it's about 7 times faster, it's about the same speed in Opera 9.64, > and over 10 times faster in Opera 10.53. I didn't bother with the other > browsers because the notion that try/catch is always inefficient > compared to the $prop function is obviously not correct. > I considering try/catch vs property existence check. What if there was a way to do it in native code? var prop = document[?"body"][?"style"]["color"] || "green"; -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: David Mark on 12 May 2010 19:33 Scott Sauyet wrote: > David Mark wrote: >> Matt Kruse wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> Matt Kruse wrote: >>>>> Thomas 'PointedEars' Lahn wrote: >>>>>>> I'm not building this for idiots! >>>>>> ISTM you are not building this for people who do DOM scripting either. >>>>>> <form>...<input name="foo[]">...</form> >>>>> This already works fine: >>>>> $prop(document, "forms[0].foo[].value") >>>>> for example. >>>> You miss the point. >>> On the contrary, you fail to make one. >> No, as usual, you waste endless amounts of time "debating" when you >> could be working. How do you ever get anything done? > > David, > > Matt, who has spend far less time debating here in recent months than > either your or I, came here asking for discussion on an API he was > designing. He has certainly gotten that. He has, unsurprisingly, > been defending the decisions he's made, but he has not shown any signs > of being unwilling to listen to criticism. His only sign of testiness > was in his response to Thomas' bald assertion, "You miss the point." Yes, thanks for the play-by-play. :) > > Thomas has made some positive contributions to this thread. That post > was not among them, and I don't fault Matt for responding in a like > manner. Who cares? > Your only contribution of substance was another bald > assertion that his single-string API is a design mistake. Another? I only made one post of that sort. > You didn't > justify it at all. It had already been discussed _to death_. Hence my post. > While I agree with you, based upon my own > experience with a similar API built some years back, your only posts > in this thread have been argumentative and not at all constructive. You don't seem to realize that my post came after yours (and others who recommended the same thing). I was agreeing with you (not the other way around). And there was no need to revisit everything that had led up to it, was there? > > It seems to me that it's you who's wasting time here. No, now it is you that is perpetuating the futility of this discussion. God knows, I tried to head it off. > > (And now me too. Damn!) That's the first sensible thing you said. ;)
From: David Mark on 12 May 2010 19:49 Scott Sauyet wrote: > Matt Kruse <m...(a)thekrusefamily.com> wrote: >> I could modify it to take any number of arguments, to support both >> ways of accessing the properties - either as a single string with no . >> in it, or as multiple strings with no limitations. > > I would suggest you don't. Make your API as clean as possible while > still meeting your requirements and then live with whatever > restrictions that entails. Of all the critiques of jQuery I've seen > here, by far the most compelling is against the re-use of "$" to mean > so many different things. Not to mention its inability to read/write/remove attributes straight, which is akin to a calculator that can't add/subtract straight. Then there is the broken query engine. I sometimes wonder if people see the results of my tests as some sort of inconvenient mirage? They demonstrate zero consistency (over the course of years) between library versions, as well as browser versions. Not to mention that they slapped QSA on top of their old mess, knowing that it would do lots of things right that the old stuff did wrong. So you get applications that appear to work in the very latest desktop browsers, but fail completely in everything else. No wonder jQuery developers refuse to test their creations in anything but the latest desktop browsers. ;) The "$" thing is only notable in that they foolishly chose the one (out of about six billion) variable names that was known to be used by similar scripts (e.g. Prototype). And yes, they use it for different purposes. Or perhaps you mean the awkward metaphor of treating everything as a collection. That's certainly the sign of an ill-fitting API. Every single thing is not multiple things. It's even awkward trying to explain its awkwardness. :)
From: Scott Sauyet on 13 May 2010 14:22 David Mark wrote: > Scott Sauyet wrote: >> Of all the critiques of jQuery I've seen >> here, by far the most compelling is against the re-use of "$" to mean >> so many different things. > > Not to mention its inability to read/write/remove attributes straight, No, I've read your comments on that ad infinitum. While you are probably right, it's not something that bothers me nearly as much as it seems to bother you. > The "$" thing is only notable in that they foolishly chose the one (out > of about six billion) variable names that was known to be used by > similar scripts (e.g. Prototype). And yes, they use it for different > purposes. As a new library, they did not have to be bound by the conventions the Prototype used. Granted, their use makes it somewhat more difficult to move between these libraries, but that's at most a minor issue. The symbol is not the issue. I have the same problem with the 'jquery' function for which '$' is an alias. > Or perhaps you mean the awkward metaphor of treating everything as a > collection. That's certainly the sign of an ill-fitting API. Every > single thing is not multiple things. It's even awkward trying to > explain its awkwardness. :) No, I actually think they got this right. Acting on a group, whether it contains one element, no elements, or many elements, is to me very useful. And it still works as an array if you want the underlying DOM elements instead. No, my problem is with the different meaning that $/jQuery takes on depending upon the parameters supplied. This is from their documentation: 1. jQuery( selector, [ context ] ) 2. jQuery( element ) 3. jQuery( elementArray ) 4. jQuery( jQuery object ) 5. jQuery() 6. jQuery( html, [ ownerDocument ] ) 7. jQuery( html, props ) 8. jQuery( callback ) The first five essentially create jQuery wrappers around existing DOM elements. The next two create new DOM elements from scratch and wrap them in a jQuery wrapper. The final one runs a function when the DOM is ready. That's two things too many that this one function should try to do. That's the issue I object to. -- Scott
From: Thomas 'PointedEars' Lahn on 13 May 2010 14:56
Scott Sauyet wrote: > David Mark wrote: >> Scott Sauyet wrote: >>> Of all the critiques of jQuery I've seen >>> here, by far the most compelling is against the re-use of "$" to mean >>> so many different things. >> Not to mention its inability to read/write/remove attributes straight, > > No, I've read your comments on that ad infinitum. While you are > probably right, it's not something that bothers me nearly as much as > it seems to bother you. That method is being referred six times in jquery-1.4.2.js, including in the pivotal jQuery() function, and used extensively by so-called jQuery plugins. So it really should bother you a little bit that it does not work properly, if at all (there are faulty feature tests and inferences everywhere, earlier versions had browser sniffing added on top of that). PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.) |