Re^4: Object Constructors - Advice of experienced OO Perl Monks

No, you didn't understand me. Sure, the code looks cleaner, but you still have the same problem. The problem is that your initialization happens with whatever your constructor is returning. So, if you are inheriting from two classes, the first constructor is going to return object1. The second constructor is going to return object2. Now, what you finally want is a single object - most likely object1 or object2. If you separate initialization from construction (and then I mean a logical separation - not a mere separation in your source code), you can just discard one of the objects (or rather, not even calling the constructor of those classes).

package MultiColoured;
our @ISA = qw /Red White Blue/;
sub new {my $self = Red->new; bless $self, shift}
sub init {
    my $self = shift;
    $self->Red::init(...);
    $self->White::init(...);
    $self->Blue::init(...);
}
...
package main;
my $obj = MultiColoured->new->init(...);
[download]

That doesn't mean MI is always possible. If in the above example Red assumes objects are hashrefs, and Blue assumes arrayrefs, MI isn't going to work. But if all the classes assume hashrefs (as most objects do), and you don't have clashes with the hashkeys, this is going to work.

But if you need to call the constructor to initialize the object, MI is going to fail.

Perl --((8:>*

Comment on Re^4: Object Constructors - Advice of experienced OO Perl Monks Download Code

Replies are listed 'Best First'.
Re^5: Object Constructors - Advice of experienced OO Perl Monks by izut (Chaplain) on Oct 06, 2005 at 16:24 UTC
We are arguing about taste here :) I dislike the MI approach, and really prefer initialize the object inside constructor to be sure my object will be instantiated correctly. Thinking about MI, your scheme is correct. Igor S. Lopes - izut surrender to perl. your code, your rules.	[reply]
Re^6: Object Constructors - Advice of experienced OO Perl Monks by izut (Chaplain) on Oct 06, 2005 at 16:36 UTC
The point is that two steps initialization is error prone. You can avoid that using the Composite scheme: class `A` has `B` and `C` class instead of class `A` is `B` and `C` class. Update: Extracted from `perltoot`: In practice, few class modules have been seen that actually make use of MI. One nearly always chooses simple containership of one class within another over MI. That’s why our Person object contained a Fullname object. That doesn’t mean it was one. Igor S. Lopes - izut surrender to perl. your code, your rules.	[reply] [d/l] [select]
Re^7: Object Constructors - Advice of experienced OO Perl Monks by Perl Mouse (Chaplain) on Oct 06, 2005 at 16:46 UTC
The fact that MI is quite hard to do in Perl, and considering that most authors make it even harder might also be an not insignificant reason why you don't see many modules making use of MI. But I'm not saying you should use MI. I'm just saying it's impolite to make it harder for others to use MI. The harder you make it for others to do things (for instance, setting magical variables without using local, not using name spaces, writing code that isn't cross-platform), the less useful your code is. Let's not forget the question of the OP: Are there any limits on what you can/can't or should/shouldn't put into a constructor?. An answer to that question is don't put initialization of your object in the constructor, because it makes it harder to do MI. `Perl --((8:>*`	[reply]
Re^6: Object Constructors - Advice of experienced OO Perl Monks by Perl Mouse (Chaplain) on Oct 06, 2005 at 16:28 UTC
Whether one likes MI or not isn't the point. It would be impolite, and rather non-perlish, to make it harder for the users of your class to do MI. `Perl --((8:>*`	[reply]


Clear questions and runnable code get the best and fastest answer
	PerlMonks