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: Matt Kruse on 12 May 2010 15:38 On May 12, 1:52 pm, Stefan Weiss <krewech...(a)gmail.com> wrote: > 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]. Yes indeed, in fact some of the code I have has that littered all over. It makes it harder to read, IMO. But it certainly has the benefits you describe. I'm also not familiar enough with the performance hit of try/catch to know if that's even a factor. In some versions of some languages, it can be quite costly to enter a try/catch block. Matt Kruse
From: Thomas 'PointedEars' Lahn on 12 May 2010 15:55 Scott Sauyet wrote: > Thomas 'PointedEars' Lahn wrote: >> [...] >> But all of this is completely unnecessary if you let the programming >> language provide the delimiter, i.e. arguments, Arrays, or a combination >> thereof. > > It's not that I disagree. But I think your arguments are overstated. > If Matt is going to publish this and promote it as an amazing tool > that will drastically increase the productivity of any web developer, > then he really should skip the string parsing and go with the more > complete API. But if he is going to use this on a few projects with a > half-dozen other coders, I would suggest that simplicity should rule. And exactly therefore string parsing is a really bad idea here, for it *complicates* matters *needlessly*. It requires the caller to think hard about what delimiter can be used, in fact it requires them to parse the argument by *themselves*, instead of just passing the arguments and let the function do all the work. I fail to see why it should be simpler to call $prop(obj, 'prop/erty..prop#erty..[prop|erty]') no, wait, the dot is already used, must be $prop(obj, 'prop/erty|.prop#erty.|[prop|erty]', '|') no, wait, there's a pipe in a name, so must be $prop(obj, 'prop/erty#.prop#erty.#[prop|erty]', '#') no, wait, that darn hash is also used, must be $prop(obj, 'prop/erty/.prop#erty./[prop|erty]', '/') no, wait, that f***ing slash is already used, too, so must be $prop(obj, 'prop/erty%.prop#erty.%[prop|erty]', '%') -- and let's hope that we don't have overlooked a cursed `%' somewhere in the real case -- instead of simply $prop(obj, 'prop/erty', '.prop#erty.', '[prop|erty]') or $prop(obj, ['prop/erty', '.prop#erty.', '[prop|erty]']) or a combination thereof. So please forgive me if I really fail to see that kind of simplicity you are talking about with the string-parsing approach. 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.)
From: Garrett Smith on 12 May 2010 15:57 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? You could put a comment: // Use try catch in case body.firstChild does not have a style property. try { var color = body.firstChild.style.backgroundColor; } catch(e) {} That's worse, because now the code comment has to explain the failure of the code to explain itself -- and for something so trivial and basic as getting a simple property. Promoting the idea of try-catch for everything, as Google does, putting FunctionDeclaration where only statement may appear is the next obvious mistake, as Google does. Someone may also mention that using try/catch is inefficient, and it is, but that is the least of the problems. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 12 May 2010 15:58 Matt Kruse wrote: > Thomas 'PointedEars' Lahn wrote: >> So property names containing `/' and `#' could not be accessed then, i.e. >> neither $prop(obj, 'property/.property./[prop#/erty]', '/') >> nor $prop(obj, 'property#.property.#[prop#/erty]', '#') >> could access e.g. >> obj["property#"][".prop/erty."]["#[prop#/erty]"] > > Are you missing the basic point that you PICK the delimiter based on > the string you are passing in? No, you are missing the point that this requires the caller to determine the delimiter, i.e. parse the argument themselves, and the callee to parse it again, when that is not necessary otherwise. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7(a)news.demon.co.uk> (2004)
From: Garrett Smith on 12 May 2010 16:10
Thomas 'PointedEars' Lahn wrote: > Scott Sauyet wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> [...] >>> But all of this is completely unnecessary if you let the programming >>> language provide the delimiter, i.e. arguments, Arrays, or a combination >>> thereof. >> It's not that I disagree. But I think your arguments are overstated. >> If Matt is going to publish this and promote it as an amazing tool >> that will drastically increase the productivity of any web developer, >> then he really should skip the string parsing and go with the more >> complete API. But if he is going to use this on a few projects with a >> half-dozen other coders, I would suggest that simplicity should rule. > > And exactly therefore string parsing is a really bad idea here, for it > *complicates* matters *needlessly*. Yep. Matt's is needlessly complex and burdens the caller with dealing with the delimiter. deepMatt(obj, "p1.p2", "."); deepAsen(obj, ["p1", "p2"]); Both create an array. `deepMatt` - parses the string, splitting on delimiter - requires caller to supply delimiter as a third argument. - can fail with unknown property name (which may contain delimiter). `deepAsen` - requires caller to supply an array. One benefit for Matt's is that it looks more like a normal property access when only "." is used. The deepAsen function is simpler and easier to use. This is a big advantage over deepMatt. Having the flexibility of dynamic property name might be an advantage in some cases, such as seen with square-bracket property accessors, so that might be another benefit realized later. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |