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

["Ross McFarland" <rwmcfa1 neces com>]

A. Pagaltzis said:
> * 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]} = [...];

that's not any less verbose than the hash stuff, and would only be a tiny
(likely insignificant) performance increase.

> 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 ') } = [ ... ];

there would be no problem with that, but why not use the actual path syntax,
especially if you're gonna call it form path

@{ $stree->get_values_from_path('12:3:2') } = [ ... ];

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

that's muppet's suggestion in his previous mail.

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

i don't think (at least i seem to remember trying to in the past) you can have
a tied and blessed scalar so i'm not sure this would work. even if it did i
think that's much ulgier than the hash stuff.

> 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.

yeah, but having 10 ways to do stuff isn't always a good idea. (heh)

> 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().

to do a depth first search on the tied tree as is something close to this
should work (not tried so it's probably slightly off, but the idea should be
intact)

sub descend
{
    my $node = shift;
    foreach (@{$node->{children}})
    {
        descend ($_);
    }
    print join ("\t", @{$node->{value}})."\n";
}

descend ($stree->{data});

> ...
> 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.

my first thoughts are that the tied interface would actually be just as fast
if not faster, it's just where the lookups happen, but i'll have to think
about that. reguardless from my preliminary expiriments performance (of the
bindings) don't seem to be an issue, and if they are, you should be using the
tree directly, not the simple interface.

> 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] ??? } = [...]

i'd have to think about it for a while to figure out if that would be
possible/reasonable. from the tie level you don't know that you're the last
one, so how would you know to return your value instead of your children.

> 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 } = [...]

if that's the case maybe, but i'm not sure, i didn't have much success there
when i first looked at simplelist, thus the ->{data} key stuff.

> 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:

i'll have to look at that.

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

heh,

-rm