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: Thomas 'PointedEars' Lahn on 15 May 2010 11:45 Scott Sauyet wrote: > Thomas 'PointedEars' Lahn wrote: >> Scott Sauyet wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> 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. >>> I can buy this: "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, is not a goal to be attained." But I'm not buying >>> your "generally applicable" clause. >> Perhaps you are misunderstanding, then. > > Maybe, but I think it's more that I disagree. ISTM you do not know what you are disagreeing with. >>> Code needs to have an reasonable domain. >> >> The domain is property access. > > Not to my mind. And perhaps that is the crux of the matter. Yes, perhaps you do not read what you are discussing about. The whole point of this was guarded property access. Read the Subject, for goodness' sake! > The language already has '[]' for property access, and a shortcut for some > simpler cases: '.'. I have little need to use a function that has the > same domain as those language constructs. Then you are in the wrong thread. The problem was that the property access `foo.bar.baz' would fail if `foo.bar' did not store a value that can have properties. As a solution, a function was suggested that does the property access instead and returned `undefined' or `null' instead of throwing an exception then. >>> It should be clear as to what it accepts and handle errors >>> consistently, but it does not have to be able to give reasonable >>> results for unreasonable input. Defining what is and is not >>> reasonable is a large part of designing an API. >> >> Property names that contain what property names may contain are not >> unreasonable input. > > So are you saying that all functions should be written to work > seamlessly with any values of their parameters that the language might > allow? [...] No, I am saying that such a property-accessing function should allow access to all properties. And I am really getting tired of explaining that to you. >>> But I find myself in an odd position here. I'm defending something I >>> don't really support, only to say that the problems aren't as bad as >>> stated. >> >> Without giving a good reason for your opinion that they are not, so you >> should ask yourself if you are trying to defend something that is worth >> defending. > > My code was not originally intended to work with DOM nodes [...] Irrelevant. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Scott Sauyet on 15 May 2010 12:34 Thomas 'PointedEars' Lahn wrote: > Scott Sauyet wrote: >> Thomas 'PointedEars' Lahn wrote: >>> Scott Sauyet wrote: >>>> Thomas 'PointedEars' Lahn wrote: >>>>> 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. >>>> I can buy this: "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, is not a goal to be attained." But I'm not buying >>>> your "generally applicable" clause. >>> Perhaps you are misunderstanding, then. > >> Maybe, but I think it's more that I disagree. > > ISTM you do not know what you are disagreeing with. And ISTM that you are trying to solve a different problem than I am. Matt hasn't chimed in here lately so it's not clear which approach is closer to his needs. I've explained clearly what my goals from the code are. You've explained what yours are. Your approach does not meet my requirements. Obviously mine does not meet yours. This is not a sign of misunderstanding, only of different requirements. >>>> Code needs to have an reasonable domain. > >>> The domain is property access. > >> Not to my mind. And perhaps that is the crux of the matter. > > Yes, perhaps you do not read what you are discussing about. The whole point > of this was guarded property access. Read the Subject, for goodness' sake! So the subject line in a USENET posting is supposed to be more important than the direction of the subsequent conversation? >> The language already has '[]' for property access, and a shortcut for some >> simpler cases: '.'. I have little need to use a function that has the >> same domain as those language constructs. > > Then you are in the wrong thread. The problem was that the property access > `foo.bar.baz' would fail if `foo.bar' did not store a value that can have > properties. As a solution, a function was suggested that does the property > access instead and returned `undefined' or `null' instead of throwing an > exception then. Right, the goal was to get the value of "foo.bar.baz" if "foo" exists and has a property "bar", which in turn has a property "baz". But that does not seem to be the only requirement. You would like it to work for any legal values of property names. I would like it to be as transparent as possible on reading the code. You're willing to sacrifice some API simplicity for your goal. I'm willing to sacrifice some completeness for mine. >>>> It should be clear as to what it accepts and handle errors >>>> consistently, but it does not have to be able to give reasonable >>>> results for unreasonable input. Defining what is and is not >>>> reasonable is a large part of designing an API. > >>> Property names that contain what property names may contain are not >>> unreasonable input. > >> So are you saying that all functions should be written to work >> seamlessly with any values of their parameters that the language might >> allow? [...] > > No, I am saying that such a property-accessing function should allow access > to all properties. First of all, if you disagree with my more general statement, why is property access a special case? Secondly, you're willing to sacrifice what is clearly a more transparent API for that ability. For my uses, I found the simple API more important than this completeness. The language already allows us to check if the properties are defined. We can always write var val = (foo && foo.bar && foo.bar.baz) ? foo.bar.baz : defaultValue; For me the entire reason to create such a function is that this is easier to comprehend on reading the code: var val = fetch("foo.bar.baz"); > And I am really getting tired of explaining that to you. Feel free to stop any time you like. >>>> But I find myself in an odd position here. I'm defending something I >>>> don't really support, only to say that the problems aren't as bad as >>>> stated. > >>> Without giving a good reason for your opinion that they are not, so you >>> should ask yourself if you are trying to defend something that is worth >>> defending. > >> My code was not originally intended to work with DOM nodes [...] > > Irrelevant. The requirements I had for my version of this are irrelevant, but your fantasies of cases like this are relevant?: | $prop(obj, 'prop/erty%.prop#erty.%[prop|erty]', '%') Perhaps we inhabit different parts of the development world. Are you in academia by any chance? In the business community I work in, we write code to solve business needs. We try to keep it as simple as possible, sacrificing simplicity for completeness only when real-world considerations force us to. Is your experience very different? -- Scott
From: Andrew Poulos on 15 May 2010 17:33 On 16/05/2010 2:34 AM, Scott Sauyet wrote: > Thomas 'PointedEars' Lahn wrote: >> Irrelevant. > > The requirements I had for my version of this are irrelevant, but your > fantasies of cases like this are relevant?: > > | $prop(obj, 'prop/erty%.prop#erty.%[prop|erty]', '%') > > Perhaps we inhabit different parts of the development world. Are you > in academia by any chance? In the business community I work in, we > write code to solve business needs. We try to keep it as simple as > possible, sacrificing simplicity for completeness only when real-world > considerations force us to. Is your experience very different? It reads like your saying that improper, or incomplete, testing is important for solving business needs? Andrew Poulos
From: VK on 15 May 2010 20:15 > > On 16/05/2010 2:34 AM, Scott Sauyet wrote: > > In the business community I work in, we > > write code to solve business needs. We try to keep it as simple as > > possible, sacrificing simplicity for completeness only when real-world > > considerations force us to. Is your experience very different? > On May 16, 1:33 am, Andrew Poulos <ap_p...(a)hotmail.com> wrote: > It reads like your saying that improper, or incomplete, testing is > important for solving business needs? Absolutely right. Just in a bit different wording: "In the applied (business) programming the code is never perfect nor it is fully AID'ed. A perfect code with the full Anti-Idiot Defense set for any possible occasion cannot be applied for practical needs during the lifetime of the generation that expresses these needs and willing to pay for their satisfaction". :-) :-| From here a simple decision to make: i) go to business and write imperfect and potentially always failure prone code, ii) go to a university and teach 1st-3rd grade students the Theory of Perfect Coding. From the 4th grade and first preliminary job offers they will loose any interest in such course so the attendance would be a perpetual problem. -- Real life is, to most men, a long second-best, a perpetual compromise between the ideal and the possible. Bertrand Russell
From: Scott Sauyet on 15 May 2010 23:06
Andrew Poulos wrote: > On 16/05/2010 2:34 AM, Scott Sauyet wrote: >> Thomas 'PointedEars' Lahn wrote: >>> Irrelevant. > >> The requirements I had for my version of this are irrelevant, but your >> fantasies of cases like this are relevant?: > >> | $prop(obj, 'prop/erty%.prop#erty.%[prop|erty]', '%') > >> Perhaps we inhabit different parts of the development world. Are you >> in academia by any chance? In the business community I work in, we >> write code to solve business needs. We try to keep it as simple as >> possible, sacrificing simplicity for completeness only when real-world >> considerations force us to. Is your experience very different? > > It reads like your saying that improper, or incomplete, testing is > important for solving business needs? I think you need to re-read the thread, or even the section you quoted. I was discussing API design and the relative benefits of API simplicity and API completeness. Thorough testing is quite important in this environment. But it's also common to document the limited set of values that a system can handle and not try to make it especially graceful if values outside that range are supplied. The environment that Thomas seems to be operating in requires that much more weight be given to completeness; you couldn't simply document that your function will not handle negative numbers. You would have to gracefully handle this illegitimate input (hopefully with at least a useful warning message!) This is a balancing act. The simplest APIs are generally less complete; The most complete ones are generally less simple. I'm afraid you can't have it all. -- Scott. |