Re^11: Introducing Class::InsideOut

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

Comment on Re^11: Introducing Class::InsideOut Select or Download Code

Replies are listed 'Best First'.
Re^12: Introducing Class::InsideOut by adrianh (Chancellor) on Feb 19, 2006 at 14:51 UTC
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.	[reply] [d/l]

Replies are listed 'Best First'.

Re^12: Introducing Class::InsideOut
by adrianh (Chancellor) on Feb 19, 2006 at 14:51 UTC

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.

[reply]
[d/l]