The child classes could have a method to create an instance from a given parent class instance, and you can implement it any way you like - rebless the object, or rebless its clone, and so on, plus all the checks you need to allow the transition. Thus, the "dirty" code stays in the class and doesn't pollute your users' code.

I follow you and thanks for your reply. I'm not sure how to go about reblessing the object though.

As i see it i could:

• Have the constructor call the method to determine the class, and immediately rebless the object as some other class. The problem i see here is that now the parent class has to have knowledge of it's child classes which i think breaks inheritance?
• Or i could interrogate the type in the main script and create a clone of a different (sub)class. This seems inefficient to me and it seems like i'm bringing the code out of the classes and into the main script.

Am i needlessly overcomplicating things?

I found this code: Stack Overflow But to be honest i'm having real trouble following what the user is doing here!

I imagined the second solution:

my $obj = 'Parent'->new;
$obj->populate(@data);
for my $child_class (@possible_child_classes) {
    if (my $new = $child_class->new_from_parent($obj)) {
        $obj = $new;
        last
    }
}
# Don't forget to handle the case that $obj hasn't changed.
[download]

In fact, the only problem why this shouldn't go to the parent class is the array of possible child classes. So, get it from outside; the parent can insist on its children implementing a method:

sub new_from_parent { die "Should be overriden.\n" }

sub rebless {
    my $self = shift;
    my @possible_child_classes = @_;
    for my $child_class (@possible_child_classes) {
        # etc. using $self instead of $obj.
[download]

And the code becomes

my $obj = 'Parent'->new;
$obj->populate(@data);
$obj->rebless(@possible_child_classes);
[download]

لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

The problem i see here is that now the parent class has to have knowledge of it's child classes which i think breaks inheritance?

As Salvor Hardin used to say, never let your sense of morals prevent you from doing what is right!

Hello Amblikai,

I would be interested to know why each data object’s class has to change. However, given that it does, I would prefer a design in which the client code knows only the parent class (i.e., the interface), and has no knowledge of the various child classes. (That is, child classes are treated as “implementation details.”) Here is a sketch of how this can be accomplished:

The chief advantage of this design is that whenever a new Widget child class is added, the only existing code that needs to change is the rebless method in Widget.pm.¹ Client code remains unaffected.

¹Update: Widget.pm must also use each of its child classes.

Hope that helps,

I have actually seen this done in a couple of other languages.   But, what was done was (basically ...) to initially instantiate an JustLoaded object, which possessed the necessary functionality to support loading things from a data source.   The programmers then provided a factory method, which would coin an instance of the proper thing and return it (or, raise an exception).   After that, the original object was discarded.

In Perl, this idea can be simplified to “re-blessing.”   Instantiate an object that has support for the loading process, then re-bless it into its target class after confirming that all of the requisite instance-variables called for by that class do exist, and that the object is otherwise “sane.”   (Or, re-bless it, then call an internal-only method that performs that sanity-check.)