note hardburn Some argue that the behavior or subclasses (or subtypes) should not change . . . I dunno. [cpan://HTML::Template::Dumper] significantly changes the behavior of [cpan://HTML::Template]. If people want to argue that this breaks Liskov, that's fine, but it doesn't stop HTML::Template::Dumper from being useful. $object->as_string One important benifit is that YAML/Data::Dumper only show the state of the object's internal data structure, but not lexicals used for storing private data (see below). It might be private, but if it's for debugging or human-readability, it might still be important to print it out. So a mere <code>Dump($obj);</code> is often not enough. Other observations: 1) One thing I often see is people storing things in the object's structure that should be private, or storing things in lexicals that should be accessible to subclasses. As a general rule, if you want a subclass to get at it, it should be in the blessed reference of the object. Or provide accessors/mutators that are only available to subclasses (not public, unless your design explicitly calls for it). If the data needs to be truely private, put it in lexicals declared at the top of the package. 2) If you have a factory method, do not hardcode the name of the class. Instead, put it in a subroutine, like this: <code> package My::Foo; sub BAR_CLASS { 'My::Bar' } sub bar_factory { my $my_class = shift; my $bar_class = $class->BAR_CLASS; bless { }, $bar_class; } </code> This better supports subclasses, which would otherwise need to override the entire <code>bar_factory</code> method (which could be extremely complex). Now they only need to say <code>sub BAR_CLASS { 'My::Bar::Subclass' }</code> to change exact output of the factory method. (It's the responsibility of the subclass to make sure <code>My::Bar::Subclass</code> implements the same methods as <code>My::Bar</code>). 3) Calling all your own methods should be done in <code>$obj->method( @args )</code> form. Not <code>method( $obj, @args )</code> or (worse) <code>method( @args )</code>. Both the bad examples break inheirtance, and the second one isn't a method at all. I could see an argument made for the <code>method( $obj, @args )</code> form if performance is a concern and you don't care about subclasses or if it's a private method, but I see no excuse for the second form. 4) Document protected methods. Unlike some other languages, Perl doesn't have any very good ways to specify what methods should only be accessible to subclasses (though it has a multitude of hacked solutions). Ultimately, you need to document your protected methods, with warnings of fire coming down from heaven if somebody on the outside uses them. And make sure fire won't come down on ligitimate subclasses. <div class="pmsig"><div class="pmsig-195718"> ---- I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident. -- [Schemer] <code>: () { :|:& };:</code> Note: All code is untested, unless otherwise stated </div></div> 317520 317520