[Dbix-class] RFC: DBIx-Class-Tree

[Dave Howorth]

Aran Deltac wrote:
> On 4/4/2006, "Dave Howorth" <dhoworth at mrc-lmb.cam.ac.uk> wrote:

>>parent - what does the code actually do if you try to make an object the
>>root? The Description says the root is the 'row with a Parent ID of 0'
>>but I can't see how that would ever get set.
> 
> Its up to you.  For example, if you parent column is parent_id then you
> could do $obj->parent_id( 0 ); or $obj->parent( 0 ), or if you're
> creating a new object you could either specify it in the ->create({
> parent_id=>0 }) or in the table definition as in "parent_id INTEGER NOT
> NULL DEFAULT 0".

I think we're at cross-purposes here. My question was what actually 
happens if I call $obj->parent(0)? My reading of the docs says it should 
set parent_id to zero; my reading of the code says it does no such thing.

>>attach_child - DBIC follows the CDBI convention of add_to_*. So why not
>>call this method add_to_children? The description could also be clearer.
> 
> Because Matt asked me to follow the DOM naming conventions, which I think
> I have to the best of my ability.  Some of the method names I've chosen
> are not directly from the DOM methods, but are heavly influenced by them.

Urgh, IMHO :) What's special about the DOM that it deserves such 
respect? And worth breaking internal consistency for? It would be nice 
to have a mention in the docs to explain the apparent inconsistency 
(ideally to the source of the names, because I haven't been able to find 
a fair few with a bit of googling).

> Its in the Ordered component.  Any method that exist in
> Tree::AdjacencyList or Ordered components is not shown in
> Tree::AdjacencyList::Ordered component.  I've added a section listing
> the methods that are made available via these other two components.  You
> would still need to read the related component's POD for detailed docs
> on the methods.

I appreciate this dilemma. As the reader in this instance, I can just 
point out that this policy makes it more difficult to use the module. If 
I were the maintainer, I might well have a different opinion :)

> A DAG is a bit of a different beast than a Tree, but I'll keep it in
> mind.  Sounds like a deffinate possibility.

Well, a tree is a special case of a DAG, so an interface that can handle 
DAGs can handle trees, but not necessarily vice versa.

Cheers, Dave