use Factory;
use Fruit;
my $apple = Factory->newObject("Apple");
$apple->doSomethingAnyGenericFruitCanDo();
[download]

package Tree;

sub add_item {
   my ($self, $item) = @_;
   my $parent_node = ...;
   $parent_node->add(new Node($item));
}
[download]

would be transfored into the following when using a factory:

package Tree;

sub add_item {
   my ($self, $item) = @_;
   my $node_factory = $self->{node_factory};
   my $parent_node = ...;
   $parent_node->add($node_factory->create($item));
}

sub set_node_factory {
   my ($self, $node_factory) = @_;
   $self->{node_factory} = $node_factory;
}

package NodeFactory;

# Overridable
sub create {
   shift(@_);
   return Node->new(@_);
}
[download]

But that's pretty useless in Perl, since it lacks the typing of Java. In Perl, you could easily accept a class name (e.g. 'Node') or a code ref (e.g. sub { Node->new(@_) }) instead of a factory.

OK, I am getting enough of what you are telling me to understand your point.

I know some of the basics of OO, and I know how to use Perl as a replacement for awk. I jumped straight into using Object::InsideOut without ever writing up my own simple Perl classes, so I'm ignorant of Perl OO implementation basics. Yesterday on the drive home I figured out that is why some of my questions come from left field and why this advice is more opaque to me than I'd like.

What still mystifies me about your code is the use of the ... operator. This is just a range operator right? I've read every paragraph of perlop that contains the '...' string, but I still don't understand you use of that operator.

Thanks.

Such diligence! But in this case, ... simply means "There's code missing here." How one finds where to insert a node into a tree wasn't relevant to the topic at hand.

# Initialize a new Z object for each element of @inits
my @obj_array = map {$z->new($_)} @inits;
[download]

# Initialize a new object of the same type as $z for each element of @
+inits
my @obj_array = map {ref($z)->new($_)} @inits;
[download]

my $obj = $factory->create_element( $node_name, @args );

# Check to see if $obj represents a 'foobar' node
if ( $obj->isa( 'foobar' ) ) {
    # Do something
}
[download]

1. My users can register new nodenames and the factory manages that
2. I have some classes that can handle more than one nodename. For example, IF and CONDITIONAL are aliases to each other and are both handled by PDF::Template::Element::Conditional.
3. In most of the code, I need to differentiate what's a container (can have children) and what's an element (can't have children). However, in the parsing code, I don't care about that (because validation is handled somewhere else).