Re-blessing objects is not cool nor evil. It's stupid. It's just asking for trouble, even when you know what you're doing. Why bother at all with "OO" if you're going to break the rules?

Ive done this quite a few times. I dont think its so bad depending on the purpose and requirements. For instance, I have a routine that returns a list of objects from a query that can perform a particular function. In fact the internals of those objects are quite complicated and expensive to fetch and more often than not I dont need to use all of the returned objects (but wont know if I do until too late), so I actually use two classes of objects. The first class has as its contents the required information to complete the building process. All of the accessor methods simply cause the object to complete the build, rebless, and then recall whatever it was that was originally called. That way I only need to do a full build on the objects I actually use. As a way of transparently encapsulating such behaviour I think reblessing is a fine way to procede. (I think in a way you could compare it to a "seed" object turning into a "Tree" object.)

Now there are times and places for everything. I wouldn't encourage a lot of reblessing, but I dont think it should be just automatically rejected. There are times where it makes perfect sense.

I would like to add the proviso that reblessing should be done
1. in as few places as possible, preferably in some set of Factory classes that are, by their nature, magical beasts
2. so as to result in intuitive changes
3. if nothing else works

Just because you can doesn't mean you should.

------
We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

My personal view is that these rules are too strong. The average code perhaps should have such rules applied, but I think early in the game its ok to decide that various features are to be handled by reblessing. For instance it wouldnt be too difficult to write a parser where the parser state is encapsulated in the class name of the object doing the parsing.

But on the whole I agree with these as strong recommendations.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi

Given, discipline is very important. But also there is some "evil" in Perl that is also cool, because, yes, deep within us all, we know that sometimes evil is cool. It is for this reason that I like listening to Heavy Metal music sometimes :) No, seriously... sticking to form is important in OO, but OO is oft controversial as to what is 'good form'.

Over-use of singletons, factories, accessors, and other P.C. methods can be disasterous to an application -- just as 'evil' can. Both 'evil' and 'good' have their uses, and 'good' in the wrong place can have 'evil' results. Thus it is important to know both the good and the evil. It's a Taoist sort of thing. Ok, I just confused myself.... Carry on!