If you want to inherit from a foreign class in this particular way (substituting the foreign object for the standard undefined scalar), reblessing must be expected.

Erm... it's perfectly possible to inherit from another class without reblessing. It's one of the major advantages of the inside-out approach. For example:

{   package MySubClass;
    use base qw( SomeHashBasedClass );
    use Class::InsideOut qw(:std);
    
    sub new {
        my $class = shift;
        my $self = $class->SUPER::new( @_ );
        return register( $self );
    }
};
[download]

You are right, thanks for pointing it out. You have the general problem that SUPER isn't guaranteed to pick up the right class with multiple inheritance.

While I don't see reblessing as evil, (what is the big problem?) I avoid it where possible. It's ugly and looks like you can't make up your mind. I guess I could come up with an alternative universal ->new that doesn't re-bless foreign objects, but that's the problem with this discussion.

We're comparing the solid Class::InsideOut with some not-yet-written counter-example of mine. I can wriggle out of any argument by redefining the example. For the moment, if you don't mind, I'd rather give it a rest until there is something more concrete to discuss. It's been instructive so far.

Anno

You are right, thanks for pointing it out. You have the general problem that SUPER isn't guaranteed to pick up the right class with multiple inheritance.

True. There's always NEXT.

While I don't see reblessing as evil, (what is the big problem?)

I don't see re-blessing as necessarily evil, and there are odd places where I will use it. However in this particular instance I'd be worried that somebody reading:

$foo = Foo->new( $bar );
[download]

will really not be expecting $bar to be reblessed into a different class since 99.9% of new() methods do not do weird side-effecty things like that to their arguments.

We're comparing the solid Class::InsideOut with some not-yet-written counter-example of mine. I can wriggle out of any argument by redefining the example. For the moment, if you don't mind, I'd rather give it a rest until there is something more concrete to discuss. It's been instructive so far.

Of course I don't mind :-)

I think the issue is that Class::InsideOut has different design goals from the system that you want. It's been very deliberately (and nicely) designed to be minimal - so that it can be used in as many situations as possible. Whereas you seem to be talking about something more like Object::InsideOut or Class::Std which are aiming to solve a bigger/different set of problems.

There is absolutely nothing wrong with your goal of separating out initialisation from object construction. It's just that it's not a design goal for C::IO.