Thank you for your post. I'm going to spend some time re-thinking my design, and seeing if this is a better way to do things.

Bear with me as I reply to your post... I'm certainly not replying because I think your way is inferior to the way I do it, because I'm new to this, so I'm not too set in my ways. But here I go...

Personally, I don't like using class membership to determine whether an object is "ok" or not. I mean, someone could use Node as a base class, but override all the methods to do anything they want anyway, so what's the point of looking for it?

Alright, so what's the point of even using my Node as a base class? If it's going to override my methods and do whatever it wants, there's really no point in inheriting from my class. But I know, this was probably just an overstatement to make a point.

I'd rather go with what is sometimes called duck typing. That is, if it walks like a duck, and talks like a duck, it must be a duck. In Perl terms, this means I like to use can to check if an object has the methods I am going to call on it.

This duck typing seems to be allowing for objects that aren't inheriting my class to use my classes methods? What's the point of that? If it's going to use them, why not just inherit?

However, I don't think I LOSE anything by using your duck typing either. This is what I like about your method, I gain the ability to cater to other classes, as long as they impliment a certain interface (basically, the specific interface of can("foo") and can("bar") ), but I don't lose anything. Basically what I'm looking for to see if an object is or at least inherits from my class probably really does mean I just want to be able to use the methods in this theoretical interface. It probably wouldn't be very good to be able to play with the internals of the object anyway (which might be what I was actually subconsciously thinking about doing).

Wait... just thinking this through quick, you're free to comment on this thinking (well, actually you're free to comment on anything in this post). I have my methods, which are an interface for users and other classes, right? But I can change how things are stored and how things are done within my class, as long as I don't break "the contract" that the methods won't change. So what about playing with the internals of a class that should be the same as mine? What I'm thinking is that, what if later on I decide that I tend to try to find a Node's children more often than it's parent? I've made a promise that I won't change my 'parent' method, but if I just modify some things, I can make 'node' store an array of children, so my $self->parent( $parent ) call might do something like push @$parent->{ children } $self;. Would that be a bad thing? (I'm not sure, I'm actually asking.) [Oh, turns out I WAS subconsciously considering playing with the internals of another object, even if it's supposed to be the same class]. Okay, so if I did end up thinking this was better, how can I modify my classes internally without breaking the contract? Or does this mean I have to do a little bit more planning up front, and that actual "not breaking the contract" deal is more for optimization of functions and storage and the like?

Once again, I re-iterate that I'm not questioning your judgement, in fact I respect it. I'm just asking questions and probing to see if I can a) think some things through myself, and b) learn from more experienced monks' wisdom.

    -Bryan