Timothy (>), Moritz (>>):
>> Speaking of Tree, let me quote from IRC:
>>
>> 09:23 < masak> it's a bit unfortunate that the identifier 'Tree' is now
>> squatted by an internal class in Perl 6, which is not
>> general
>> enough to reprenest an arbitrary tree data structure.
>>
>> I fully agree with that. If it's not the most general tree, don't name
>> it Tree.
>
> Hmm. I'm wanting the API for this tree structure to be able to
> represent arbitrary general trees. I'm limited by the fact that the main
> trees I'm familiar with are filesystems and XML, and a little with LDAP.
> Can you give examples of types of tree that aren't representable with what
> I'm doing?
I'll give it a shot. As previously seen in S16:
role Tree does Tree::Node {
has Tree::Node $root; # The root directory
has Tree::Node $cwn; # The current working directory (node)
has Bool $can_multiple_parent; # Nodes can have multiple parents
has Bool $can_link; # Unix links, Windows shortcuts, etc
}
A tree is a graph without cycles. The concept of a "root" is very
common in computer representations, but in no way necessary for a
general tree. In fact, in phylogenetics, it's business as usual to
handle unrooted trees. This makes the $root attribute meaningless in
at least some cases.
The $cwn is meaningless in most tree implementations I can think of.
As to $can_multiple_parent, a structure which allows nodes with
multiple parents is not a tree, it's a directed graph. Whether
symlinks are allowed is (1) fairly filesystem-specific, and (2) not
very pertinent to the tree object itself.
What's left is, in effect, this:
role Tree does Tree::Node {
}
While an empty role _does_ indeed have potential, and could be made to
work with most tree implementations out there, it's also a bit of a
shame to pretend to provide four attributes with Tree, neither of
which is actually an attribute of a general graph-theoretical tree.
Just sayin'.
Another thing I found myself saying yesterday was that "designing a
language also involves knowing when not to decide things for the
programmer." I wish there was a way to say this, while also
emphasizing my appreciation for the many good changes to S16. Files
and I/O are obviously areas where the bikeshedding tendency grows
extra strong, so I'm glad someone actually goes in and does things to
the spec.
But I do believe that creating a general tree role of the above kind
would be unfortunate in at least two ways: it'd limit the possible
implementations of trees (while not giving much back in terms of an
advantage), and it'd use up the perfectly good name "Tree". I'd say
keep it simple, keep directory structures and XML DOM trees separate,
and don't let Perl second-guess what you want to implement.
// Carl
