Re: Gtk2::Simple::Tree (preview)

["A. Pagaltzis" <pagaltzis gmx de>]

* Ross McFarland <rwmcfa1 neces com> [2004-04-15 13:29]:
> basically my reasons against it where it makes for unreadable
> code:
>
> @{$stree->{data}[12][1][3][1][2][0]} = [...];
>
> if you're new at things and you see that you're likely to run
> away screaming. whereas 
>
> @{$stree->{data}[12]{children}[3]{children}[2]{values}} = [...]

Or you just use some constants.

@{$stree->{data}[12][CHILDREN][3][CHILDREN][2][VALUES]} = [...];

> by far the most common case (especially with SimpleTree) is a
> two level list. categories and members of those categories. in
> that situation the hash version doesn't get too ulgy. 

True.

Ok, stream of consciousness rambling coming up.

I'd really prefer one or both of two other options be also
offered:

# Nr.1
@{ $stree->get_values_from_path(' 12 / 3 / 2 ') } = [ ... ];

# Nr.2, similar
@{ $stree->get_values_from_path( qw/ 12 3 2 / ) } = [ ... ];

# Nr.3
@{ $stree->get_child(12)->get_child(3)->get_child(2)->get_values } = [ ... ];

In fact the path calling styles could both be implemented in the
same method: distinguishing them would be a matter of checking
the number of parameters passed.

Of course implementing both options 1/2 and 3 at the same time is
no issue at all.

Thinking about it, I think *each* of these options can be useful,
each in its own situation. So maybe they *should* be all be
implemented. It can be argued that if all of these are
implemented, there should also be a get_child_from_path(), so
that you could descend the tree incrementally with a path just as
you can with get_child().

Of course, at that point both are semantically completely
equivalent and thus get_child() could be omitted entirely.
Or maybe get_path() could be folded into get_child instead:

@{ $stree->get_child( 12, 3, 2 )->get_values } = [ ... ];

I think I like that best. Although in that case I'd argue that
the string path functionality should be separated out, so there'd
still be a get_child_from_path().

Hmm.

Thinking about it I like this last proposition best. In fact,
something like get_child( 12, 3, 2 ) would offer a performance
advantage over the tied interface if it doesn't internally go
through it.

As an aside, get_values() could be an lvalue method, which would
let us simply write

$stree->get_child( 12, 3, 2 )->get_values = [...]

Although that looks strange -- the method should really be called
just values() then.

The tied interface would still be useful for building the
structures in the first place for such things as persistence
though, so it certainly shouldn't be ditched.

Hmm.

So why do I like that so much better than the tied interface?
Mostly, because it's concise. In saying that, I am realizing that
what is really annoying about this

@{$stree->{data}[12]{children}[3]{children}[2]{values}} = [...]

is the fact that obviously, we'll only ever the "values" key once
we reach the end of the path, so the repeated "children" lookups
on the intermediate steps are redundant. It offers no futher
clarity over something like

@{ $stree->{data}[12][3][2] ??? } = [...]

And that is how the tied interface really should look. Of course
the question is what do we use in place of "???".

Right now, I'm not quite sure, but still rather certain that I
remember it's possible to have $foo both behave like a tied
arrayref $foo[42] as well as an object $foo->bar(). Then it would
simply be

@{ $stree->{data}[12][3][2]->values } = [...]

I am also thinking of MJD's ArrayHashMonster.

@{ $stree->{data}[12][3][2]{values} } = [...]

In fact, with ArrayHashMonster and even more dark magick we could
do this:

@{ $stree->{data}{12, 3, 2}{values} } = [...]

But that's getting out of hand and I don't really feel
comfortable with this.

What, you're still reading? Impressive display of stamina there,
lad.

-- 
Regards,
Aristotle
 
"If you can't laugh at yourself, you don't take life seriously enough."