in reply to Feedback on Class::Container

From reading the "Scenario" section of the pod, this sounds like "factory methods." Passing the parent class constructor parameters to initialize a child class is a bit unorthodox. Normally, you'd either pass these to the child class constructor, which would filter out the ones it wants, and pass the rest to its parent, or make a factory method in the parent, like so:
sub Parent::factory { my $type = shift; # ... $type->new(@_); }
This way each constructor takes what it wants, and if there are leftovers in the base class constructor, it can signal an error.

/s

Replies are listed 'Best First'.
Re: Re: Feedback on Class::Container
by kwilliams (Sexton) on Jul 01, 2002 at 01:41 UTC

    educated_foo wrote:
    From reading the "Scenario" section of the pod, this sounds like "factory methods."

    Yes, it can definitely be used that way, but it can do more too. It supports simple "has-a" relationships, "factory" relationships, and "uses" relationships.

    Also, you're talking about "parent" or "child" - it seems like you're thinking of @ISA inheritance, but Class::Container is focused primarily on containment relationships.

    Assuming you really did mean containment relationships, if I used a bottom-up approach like the one you're suggesting, I'd have to manage lots of bottom-level objects instead of just one top-level object. That seems very inconvenient. It is supported by Class::Container if you want to do that, though - you can affect a contained object "wheel" (of class "Wheel") when creating the "car" (of class "Car") by any of these three approaches:

    • pass constructor parameters for the default "Wheel" class to the "Car" constructor
    • pass a "wheel_class" parameter to the "Car" constructor that could change the wheel's class to "My::Wheel", optionally including any additional parameters that "My::Wheel" takes
    • pass an already-created "wheel" object to the "Car" constructor
    -Ken