Does anyone here use a general convenience method for deep property access that will not throw an error if any property along the chain is undefined?
For example:
deep(document, "body.firstChild.style.backgroundColor"); or deep("myElementId.childNodes[3].id"); or deep( myJsonObject, "locations.ca.sandiego.directory.people.smith.john.phone");
This would return undefined if any element along the chain is not there, or index is out of bounds, etc. If the chain gets to the end, it would return the last-evaluated value. This would be convenient for accessing deep properties of objects that may or may not exist, and not having to manually check the chain in your code.
I'm curious to know if anyone uses such an approach, or the cons of doing so.
On May 11, 9:44 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> Does anyone here use a general convenience method for deep property > access that will not throw an error if any property along the chain is > undefined? [ ... ]
> I'm curious to know if anyone uses such an approach, or the cons of > doing so.
I used such a technique only once. It was easy enough to write, performed well enough for my uses, and did simplify some code. But as new developers came aboard the project, it was one more thing that they hadn't seen before, and it rarely turned out to be useful enough to justify even the short learning curve.
But then again I don't think I've ever written something as deep as your third example.
Matt Kruse wrote: > Does anyone here use a general convenience method for deep property > access that will not throw an error if any property along the chain is > undefined?
> For example:
> deep(document, "body.firstChild.style.backgroundColor"); > or > deep("myElementId.childNodes[3].id"); > or > deep( myJsonObject, > "locations.ca.sandiego.directory.people.smith.john.phone");
getFeature() and isMethod() in JSX:object.js do a similar thing. They could be rewritten to support your requirements using dotsToBrackets() in JSX:types.js. Note that I had opted for several arguments instead because property names may contain `.', `[', or `]'.
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$8300d...@news.demon.co.uk> (2004)
On May 11, 8:44 am, Matt Kruse <m...@thekrusefamily.com> wrote:
> Does anyone here use a general convenience method for deep property > access that will not throw an error if any property along the chain is > undefined?
Well, here's my stab at it:
/* Error-Free Deep Property Access!
Returns: Property value, or undefined if any part of the property chain is undefined
*/ var $prop = (function() { var last_match; return function(a,b) { // Calls to $property() return the last match if (typeof a=="undefined") { return last_match; }
var context, props = null, p; // If first arg is not a string, assume it's an object to // start from if (typeof a!="string") { context = a; props = b.split("."); } // Otherwise it's just a string where the first part is an // element ID else { props = a.split("."); context = document.getElementById(props.shift()); if (!context) { return; } } while (context && props.length>0) { if (context==null) { return; } p = props.shift(); // If there is an array index [i] at the end, only // process the first part and stick the second part // back on the beginning if ( p.match(/(.+?)(\[\d+\].*)/) ) { p = RegExp.$1; props.unshift(RegExp.$2); } // if the first part itself is an array index [i] // then process it if ( p.match(/^\[(\d+)\]$/) ) { if (!context || !context.length) { return; } context = context[RegExp.$1]; } // If it's a function(arg) call else if ( p.match(/(.*)\((.*?)\)/) ) { context = context[RegExp.$1](RegExp.$2); } // Else it's a regular property else { context = context[p]; } if (typeof context=="undefined") { return; } } last_match = context; return context; }
Matt Kruse wrote: > On May 11, 8:44 am, Matt Kruse <m...@thekrusefamily.com> wrote:
>> Does anyone here use a general convenience method for deep property >> access that will not throw an error if any property along the chain is >> undefined?
> Well, here's my stab at it: [ ... ]
So this won't allow, for instance,
$props("myObj.prop1.prop2[current.value]")
Is that right? It needs to have only a single root at the first token. That will cover a lot of possibilities, but the more general case is interesting too.
On May 11, 12:19 pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
> So this won't allow, for instance, > $props("myObj.prop1.prop2[current.value]") > Is that right? It needs to have only a single root at the first > token. That will cover a lot of possibilities, but the more general > case is interesting too.
True. But since you're passing in a string, couldn't you just do:
Matt Kruse wrote: > On May 11, 12:19 pm, Scott Sauyet <scott.sau...@gmail.com> wrote: >> So this won't allow, for instance, >> $props("myObj.prop1.prop2[current.value]") >> Is that right? It needs to have only a single root at the first >> token. That will cover a lot of possibilities, but the more general >> case is interesting too.
> True. But since you're passing in a string, couldn't you just do:
> $prop("myObj.prop1.prop2."+current.value) > ?
Generally, no. Think about it. See also the caveats that I have mentioned.
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
Matt Kruse wrote: > On May 11, 12:19 pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
>> So this won't allow, for instance, >> $props("myObj.prop1.prop2[current.value]") >> Is that right? It needs to have only a single root at the first >> token. That will cover a lot of possibilities, but the more general >> case is interesting too.
> True. But since you're passing in a string, couldn't you just do:
> $prop("myObj.prop1.prop2."+current.value) > ?
Sure, unless current is undefined, which I think is the original problem we're trying to solve. :-)
Scott Sauyet wrote: > Matt Kruse wrote: >> On May 11, 12:19 pm, Scott Sauyet <scott.sau...@gmail.com> wrote: >>> So this won't allow, for instance, >>> $props("myObj.prop1.prop2[current.value]") >>> Is that right? It needs to have only a single root at the first >>> token. That will cover a lot of possibilities, but the more general >>> case is interesting too.
>> True. But since you're passing in a string, couldn't you just do:
>> $prop("myObj.prop1.prop2."+current.value) >> ?
> Sure, unless current is undefined, [...]
Wrong. Think about what would happen with
current.value = 42;
or
current.value = "foo.bar";
or
current.value = "foo['bar']";
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$8300d...@news.demon.co.uk> (2004)
Matt Kruse wrote: > if ( p.match(/(.+?)(\[\d+\].*)/) ) { > p = RegExp.$1; > props.unshift(RegExp.$2);
Other flaws of this approach that I have already mentioned aside, the `$n' properties of `RegExp' are deprecated as of JavaScript 1.5 at least. Use the return values of String.prototype.match() and RegExp.prototype.exec(), respectively, instead.
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
Matt Kruse wrote: > Does anyone here use a general convenience method for deep property > access that will not throw an error if any property along the chain is > undefined?
> For example:
> deep(document, "body.firstChild.style.backgroundColor"); > or > deep("myElementId.childNodes[3].id");
Square bracket notation allow to used returned result by expression, and that result is not bound as Identifiers rules defined by ECMA-262. With your strategy you would have problems. For example:
var obj = {}; obj['.prop.'] = true; obj['[prop]'] = true;
print(obj['.prop.']); print(obj['[prop]'])
Your strategy is too complex and implementation will be terrible any time. For example you can use evil for your purposes:
eval(properties);
Of course that is not solve the design problems. I will prefer to use array which contain each property name. For example:
On May 11, 1:06 pm, Scott Sauyet <scott.sau...@gmail.com> wrote:
> > True. But since you're passing in a string, couldn't you just do: > > $prop("myObj.prop1.prop2."+current.value) > > ? > Sure, unless current is undefined, which I think is the original > problem we're trying to solve. :-)
I think it's good to solve the most general case that is reasonable and useful, but not EVERY general case.
> And of course we could want > $props("myObj.prop1.prop2[current.deeply.nested.value]") > as well.
Sure, you COULD do that, but I don't imagine I ever WOULD. So solving that case holds little value for me. But using my function, I suppose you could do:
if ( $prop("current.deeply.nested.value") ) { $prop("myObj.prop1.prop2."+$prop())
On May 11, 2:45 pm, Asen Bozhilov <asen.bozhi...@gmail.com> wrote:
> Square bracket notation allow to used returned result by expression, > and that result is not bound as Identifiers rules defined by ECMA-262. > With your strategy you would have problems. For example: > var obj = {}; > obj['.prop.'] = true; > obj['[prop]'] = true;
> print(obj['.prop.']); > print(obj['[prop]'])
> Your strategy is too complex
But why would you EVER do that? I'm not building this for idiots!
> and implementation will be terrible any > time.
I don't know, my implementation is pretty straight-forward and works well.
> For example you can use evil for your purposes: > eval(properties);
Which will still throw errors.
> I will prefer to use > array which contain each property name. For example: > deep(context, ['property1', 'property2', 'propertyN']);
How is that any better than joining the array with "." and passing a single string?!
Matt Kruse wrote: > Asen Bozhilov wrote: >> Square bracket notation allow to used returned result by expression, >> and that result is not bound as Identifiers rules defined by ECMA-262. >> With your strategy you would have problems. For example: >> var obj = {}; >> obj['.prop.'] = true; >> obj['[prop]'] = true;
>> print(obj['.prop.']); >> print(obj['[prop]'])
>> Your strategy is too complex
> But why would you EVER do that?
It can be necessary for mapping values that property names contain dots or brackets.
> 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>
> [...] >> I will prefer to use array which contain each property name. For example: >> deep(context, ['property1', 'property2', 'propertyN']);
> How is that any better than joining the array with "." and passing a > single string?!
You want to re-read the thread and re-think your question.
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$8300d...@news.demon.co.uk> (2004)
Matt Kruse wrote: > On May 11, 2:45 pm, Asen Bozhilov <asen.bozhi...@gmail.com> wrote: >> I will prefer to use >> array which contain each property name. For example: >> deep(context, ['property1', 'property2', 'propertyN']);
> How is that any better than joining the array with "." and passing a > single string?!
It's more general, not necessarily better. But it does address the issues Thomas raises, and allows for the generality I was suggesting. If your simple cases are all you ever need, by all means use a simpler strategy.
It also has the advantage that you can pass variables holding strings without manual concatenation. The only thing I would do differently than the above is that I would remove the array and deal with variable arguments; this seems cleaner to me:
This still does not get at the even more general solution I mentioned, and which I tried to implement some time ago. But of course that solution had the problem yours does with property names containing periods or brackets. I used an escape syntax for those, and that's where some of the clean API went up in smoke.
I will see if I still have a copy of that code at home. I'm curious to see how much five-year-old code might make me shudder.
Matt Kruse wrote: > Asen Bozhilov wrote: > > I will prefer to use > > array which contain each property name. For example: > > deep(context, ['property1', 'property2', 'propertyN']);
> How is that any better than joining the array with "." and passing a > single string?!
At all you miss the point and wrote in arrogant way that reply. Could you show an implementation which works with:
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.
Matt Kruse wrote: > On May 11, 2:45 pm, Asen Bozhilov <asen.bozhi...@gmail.com> wrote: >> Square bracket notation allow to used returned result by expression, >> and that result is not bound as Identifiers rules defined by ECMA-262. >> With your strategy you would have problems. For example: >> var obj = {}; >> obj['.prop.'] = true; >> obj['[prop]'] = true;
>> print(obj['.prop.']); >> print(obj['[prop]'])
>> Your strategy is too complex
> But why would you EVER do that? I'm not building this for idiots!
On May 11, 4:24 pm, Asen Bozhilov <asen.bozhi...@gmail.com> wrote:
> At all you miss the point and wrote in arrogant way that reply.
I don't think the reply was at all arrogant, but we may have a separation in language.
> 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.
Matt Kruse wrote: > Scott Sauyet wrote: >> this seems cleaner to me: >> deep(context, 'property1', 'property2', 'propertyN');
> Would it handle this:
> deep(context, 'prop1[0]')
> if 'context' has no property named 'prop1'?
No, for it would be looking for a property named `prop1[0]'. To look up the `0' property of the object referred to by the `prop1' property, you would of course call it so:
deep(context, 'prop1', 0)
> And what if 'context' has a property named 'myarray[0]' which is an > array?
> deep(context, 'myarray[0][0]')
> ?
deep(context, 'myarray[0]', 0)
or
deep(context, ['myarray[0]', 0])
Which one you prefer would depend on the purpose. For example, for JSX:isMethod/areMethods() I used additional arguments for property names that are part of the same member expression, and a trailing additional array argument for names of properties that are properties of the same object, i.e.
jsx.object.areMethods(foo, 'bar', ['baz', 'bla'])
returns `true' iff both `foo.bar.baz' and `foo.bar.bla' refer to supposedly callable objects that are referred to by properties of an object (in short: methods).
Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >>> Asen Bozhilov wrote: > [...] >> You want to re-read the thread and re-think your question.
> I want you to stop taking your personal frustrations out on this NG.
It was merely a hint, stupid, and you managed to miss it.
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$8300d...@news.demon.co.uk> (2004)
Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote:
>> Thomas 'PointedEars' Lahn wrote: >>> Garrett Smith wrote: >>>> Asen Bozhilov wrote: >> [...] >>> You want to re-read the thread and re-think your question. >> I want you to stop taking your personal frustrations out on this NG.
> It was merely a hint, stupid, and you managed to miss it.
That is exactly what I am talking about. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/