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: Scott Sauyet on 13 May 2010 15:34 Thomas 'PointedEars' Lahn wrote: > Scott Sauyet wrote: >> [ ... ] 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]') > [ ... ] > So please forgive me if I really fail to see that kind of simplicity you are > talking about with the string-parsing approach. I think you're setting up a straw man here. Considering that when I did my equivalent, I only once found the need for a delimiter other than the default ".", I'd be surprised if others have so many such strange strings used to identify data in their objects. If almost all the cases you have look like: $prop(obj, "path.to.property") or $prop(obj, "longer.path.with.some[0].brackets.included"); and it's only the rarest time when you need $prop(obj, "geo|lat38.900318|long-77.036562, "|"); then this syntax seems much cleaner than $prop(obj, "path", "to", "property") or $prop(obj, ["path", "to", "property"]) Of course _de gustibus non disputandum est_, but that's my take. And I still suggest that if he wants to handle DOM elements that might have brackets in their ids or the more complicated cases I mentioned, that he does go with the multiple strings. But it's not that the alternative choice is so bad. -- Scott
From: Thomas 'PointedEars' Lahn on 13 May 2010 16:41 Scott Sauyet wrote: > Thomas 'PointedEars' Lahn wrote: >> Scott Sauyet wrote: >>> [ ... ] 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]') >> [ ... ] >> So please forgive me if I really fail to see that kind of simplicity you >> are talking about with the string-parsing approach. > > I think you're setting up a straw man here. [...] I think you don't know what that is. > If almost all the cases you have look like: > > $prop(obj, "path.to.property") > > or > > $prop(obj, "longer.path.with.some[0].brackets.included"); So, is `some' the property name or is it `some[0]', which is entirely possible and realistic with DOM scripting? > and it's only the rarest time when you need > > $prop(obj, "geo|lat38.900318|long-77.036562, "|"); > > then this syntax seems much cleaner than > > $prop(obj, "path", "to", "property") > > or > > $prop(obj, ["path", "to", "property"]) > > Of course _de gustibus non disputandum est_, but that's my take. As has been pointed out already, it is not just a matter of taste, but of code quality, of efficiency and reusability. You will have quite a hard time using variable property accesses with string parsing. You will also be unable to simply copy-paste calls if any new call contains the previous delimiter in a property name. You will not have those issues with separate arguments or array elements because you do not have to care about delimiters; you will not have to split the string before, you will not have to parse anything, and you will not have to create a number of extra objects in the process. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Scott Sauyet on 13 May 2010 17:07 Thomas 'PointedEars' Lahn wrote: > Scott Sauyet wrote: >> Thomas 'PointedEars' Lahn wrote: >>> $prop(obj, 'prop/erty..prop#erty..[prop|erty]') >>> [ ... ] >>> So please forgive me if I really fail to see that kind of simplicity you >>> are talking about with the string-parsing approach. > >> I think you're setting up a straw man here. [...] > > I think you don't know what that is. I do. I simply refuse to believe you're ridiculous enough to think that the example above is a reasonable use of this sort of convenience API. If you really do, then you're right, it's not a straw man, it's plain idiocy. -- Scott
From: David Mark on 13 May 2010 18:43 Thomas 'PointedEars' Lahn wrote: > 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). > > Exactly. I can't imagine where the "probably" qualification came from. Demonstrably right would seem to be more appropriate. The SlickSpeed tests demonstrate that the queries have been an ever-shifting and inaccurate mess for years as well. It's like new readers don't believe their eyes and those who have been here for more than one cycle of criticism complain that they've already seen it. Probably?! I say definitely (for anyone with a brain). An exception would be those apologists that see the ever-changing array of errors and miscounts as a checklist of things they don't "care" about. Of course, they likely didn't know they existed before I demonstrated the issues, so I wonder how they decided on that stance. :) It's more like they are defending past assertions that have been clearly proven wrong (e.g. jQuery doesn't sniff browsers, jQuery isn't full of mistakes, jQuery isn't bad code, etc., etc.) Then there are those who see jQuery and the rest as some sort of single connected entity called "open source". In other words, any criticism of any of them is evil as so many people have put in so many hours for so little... I don't know what those people are thinking either. The jQuery bunch (for one) exist to sell dubious books. They aren't helping anything with their incompetent coding and wrongheaded blog entries. How could they be?
From: Thomas 'PointedEars' Lahn on 13 May 2010 19:32
Scott Sauyet wrote: > Thomas 'PointedEars' Lahn wrote: >> Scott Sauyet wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> $prop(obj, 'prop/erty..prop#erty..[prop|erty]') >>>> [ ... ] >>>> So please forgive me if I really fail to see that kind of simplicity >>>> you are talking about with the string-parsing approach. >> >>> I think you're setting up a straw man here. [...] >> >> I think you don't know what that is. > > I do. I simply refuse to believe you're ridiculous enough to think > that the example above is a reasonable use of this sort of convenience > API. If you really do, then you're right, it's not a straw man, it's > plain idiocy. You miss the point. The example was chosen because it points out the inherent flaw of this approach. You can create a better, IYHO less idiotic, example to demonstrate the issue. Neither changes the fact that this issue exists and that it creates a problem and complexity in the field in which it is supposed to be used, and which it is supposed to simplify. A helper function that by design makes it hard for it to be reused, that makes code less legible and less reliable than if it was not used, a function that is not generally applicable, is not a goal to be attained. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16 |