Object traverse method about sugar HOT 11 CLOSED

Ahh... I actually have something like this in another project not for traversal but for setting up namespaces... in fact it's called Namespace:

Namespace('Attic.Dust.Quantities.First', { foo: 'bar' });

would effectively do this:

var Attic = { Dust: { Quantities: { First: { foo: 'bar' }}};

... if the namespace already exists it does nothing and keeps traversing. Let me think about this one and some more use cases...

from sugar.

Wait, not I'm not so clear on the need for this. Is it simply because the property or parent property may not be defined? As in what coffeescript tries to do with some?.prop?.erty??

from sugar.

No not at all. I have had this usecase before and created my own functions to solve it. Of course now I can't remember what the use case was exactly.. it has been a while. But here's a good one, I think.

Consider the invoke method. It is very useful, but sometimes you want to invoke a nested method on an array of hashes, not just a surface-level method. Maybe you're dealing with legacycode, maybe it's by your design, maybe third party, who knows. But this is a suitable place for a traversal method.

from sugar.

Hmm... ok... because in your first example it seems that you're just doing a get on a property, but the idea is that it can also invoke functions? Is that the main idea or is it more that it can sort of "do it all"?

from sugar.

Do it all.

The problem is this: what does one do when they need to access something nested in an object, but do not have direct access to said object? This problem is especially severe in in the case of a hash of said objects, and you need to access the same thing on each one.

It is also powerful. You could insert variables into the traversal path, thereby getting various different values from a hash based on some initial set of conditions. It's hard to think of examples but I am pretty sure this is quite powerful.

from sugar.

Any more thoughts on this? Hope all is well!

from sugar.

Sorry for taking so long... I've been working on other stuff, other Sugar stuff included.

Looking back on this, it is interesting, but again the only need for it is to save checking if upper level objects on a hash exist, before either getting a property or calling a method, correct? In other words:

path.to.property = 3;

When you're not sure if path or to exist. If they don't exist then initialize them as an empty hash, is that correct?

from sugar.

I don't fully follow so either no or not-fully. I'll quote myself from above:

Consider the invoke method. It is very useful, but sometimes you want to invoke a nested method on an array of hashes, not just a surface-level method. Maybe you're dealing with legacycode, maybe it's by your design, maybe third party, who knows. But this is a suitable place for a traversal method.

from sugar.

Right, so where normally you would do this:

path.to.method('an argument')

You could now do this:

Object.traverse('path.to.method', 'an argument');

The only reason for the extra syntax is that an error would not be thrown if path, to, or method are not defined. If any of those are undefined, then simply nothing would happen. Likewise if you are getting a property like the following;

var f = Object.traverse('path.to.property');

If path, to, or property are undefined then f will simply be undefined. Finally, if you are setting a property like this:

Object.traverse('path.to.property', 'some value');

If path, to, or property are undefined then they will be created and the property set as if they did exist. So, does all that sound correct?

from sugar.

So, I think I'm going to close this issue out. I pondered it for awhile, and I can see some benefit, but more for setting a property where you don't know if the namespace exists. The benefit of trying to call a method or access a property that may or may not exist, however, seems a little more murky, and I'm not sure the added benefit here. I think I would rather know ahead of time if that method exists than send blind calls to it in the dark. I may still be misunderstanding the nature of the method, but I think that it's precisely the murkiness around it that makes it questionable the value it would add to Sugar.

In fact, it had come down to this method or Object.watch that I was debating to implement or not (Object.watch has it's own downsides with less than full browser support) and I went with that one instead. May come back to this but I think if it is to end up in Sugar it will need to have a bit more focus and be more understandable than where it's at right now.

from sugar.

Agreed. I will post use-case(s) if they come up. Thanks Andrew.

from sugar.