Re: Re: Re: Re: Reblessing

[frag]

I've come into this discussion late, but there's something about the way you're (or rather, everyone) is phrasing this issue that's really confusing me.

It seems to me that the question is whether:
a) to have multiple possible server objects, and change the identity of an existing server object on the fly via reblessing
b) to have a single connection object of fixed class, which points to a server object, and replace that server object on the fly by creating a new server object, rather than just reblessing the one that's already there

In either case, the issue about defining the messages/protocol still comes into play, and would probably be a solved by something like having "generic" messages in a top-level Server class, while having more particular message sets defined in subclasses. (Or else a Message class heirarchy, inherited by different members of the Server heirarchy.) Resolving this issue seems to me to be orthogonal to the question of whether or not to choose a) or b).

That question of reblessing seems to depend on how you need to treat the attributes of the existing server object. Do you want to pass them along to the next object, without any additional changes or tests, and without (I think) calling DESTROY when the original server object "goes away"? Then go ahead and rebless. Or would that be awful, say because the server subclasses have totally different attributes, and you can't just pass the attributes of a ServerX object into a ServerY? Then don't rebless.

What am I missing here?

-- Frag.