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 12 May 2010 09:52 Matt Kruse wrote: > On May 11, 4:24 pm, Asen Bozhilov <asen.bozhi...(a)gmail.com> wrote: >> Could you show an implementation which works with: >> var obj = { >> property : { >> '.property.' : { >> '[property]' : true >> } >> } >> }; >> $prop(obj, 'property[.property.][[property]]'); >> I expect `true' instead of `undefined'. So when you show that >> implementation we can again talk about the complex of the problem >> which you try to solve. > > That is a more complex problem, yes. But it's one that _you_ are > proposing to solve, not me ;) > > I will gladly limit the potential situations for which my solution > will apply, which for my case will probably cover 99.9% of the cases. > In the rare cases where it doesn't, I'm happier with writing context- > specific code rather than extending my solution to a more general, > obscure case. Right, that is fairly obscure. But Thomas gave an example that is quite realistic: | <form>...<input name="foo[]">...</form> A number of server-side environments might generate something like that. The question then is whether you want your solution to work for those fairly common cases or if you are just as happy writing context- specific code for them. I did check for my old code last night and couldn't find anything from that project. (It's not really mine anyway, but the client would almost certainly give me permission to share it.) But it was single- String-based like yours rather than multiple parameters as Thomas and Asen are suggesting. And I did work with the more complex cases, but as I did so, the code became more brittle and harder to use. Eventually we abandoned it altogether. If you want just the simple cases, then a single string is still okay. But if you want to handle even reasonably common more complex cases, then I would suggest that you use a multiple string parameter version, whether in an array or not. -- Scott
From: Asen Bozhilov on 12 May 2010 10:08 Garrett Smith wrote: > Asen Bozhilov wrote: > > Of course that is not solve the design problems. I will prefer to use > > array which contain each property name. For example: > > > deep(context, ['property1', 'property2', 'propertyN']); > > Does deep check own or prototype? The meaning of _deep_ here is not related with prototype chain. The deep here is used as deep level of property accessing instead. But if I should implement that method I will use square bracket notation for each property and that will lookup in prototype chain. I do not see any reasons to handle only own properties.
From: Asen Bozhilov on 12 May 2010 10:13 Matt Kruse wrote: > Asen Bozhilov wrote: > > > Could you show an implementation which works with: > > var obj = { > > property : { > > '.property.' : { > > '[property]' : true > > } > > } > > > }; > > $prop(obj, 'property[.property.][[property]]'); > Easy. I just modified the function to accept an optional last > parameter of delimiter. > So in this case you could just do: > > $prop(obj, 'property|.property.|[property]', '|') That produce unreadable and unnatural code. If you want to use string instead of list with properties, why not use just one notation? For example you can use only dot notation and do restrictions on property names cannot hold dot in their names. That will solve your problems, and allow you to use simple code for parsing property names.
From: Matt Kruse on 12 May 2010 10:19 On May 12, 8:38 am, David Mark <dmark.cins...(a)gmail.com> wrote: > Matt Kruse wrote: > > On May 12, 7:20 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> > > wrote: > >> No, by contrast you will not be able to handle property names that contain > >> `|'. > > Umm, then you just pick a different delimiter that doesn't conflict > > with your property names. Duh. > And you still can't see why you are making a colossal design mistake? > Don't parse strings. Pass multiple arguments or an array of strings. > There you go. I wouldn't say it's a colossal design mistake. It's a limitation, in order to have the convenience of a single string to identify the property. It's easier to read, and will work just fine almost all common cases. 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. Matt Kruse
From: Scott Sauyet on 12 May 2010 10:32
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." 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. Your only contribution of substance was another bald assertion that his single-string API is a design mistake. You didn't justify it at all. 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. It seems to me that it's you who's wasting time here. (And now me too. Damn!) -- Scott |