[crossfire] 2.0 object-type refactoring

[Alex Schultz]

Mark Wedel wrote:
> <snip>
>   If the new callbacks have more/different parameters than the old function, 
> then you have to go back to the old function and change it around a little bit. 
>   Any functions so called may need other changes - they may generate error 
> messages if the object type isn't handled for example, or possibly other issues. 
>   The question then becomes if it is worth it to do changes/debugging vs just 
> change the function, move it to the new code and callback method.\
>   
Well, I would say that in most cases, the callback parameters shouldn't
be much different than the old function and that where it does change it
shouldn't be much of a pain to handle. IMHO it would be worth it.

> <snip>
>   If it is always called, to a great extent, it then limits the usefulness of 
> the callback structure as a whole (it limits what can be done with the object).
>
>   If the actual type handlers make the callback to the base function, that is 
> fine - it just needs to be clearly defined that is what should be done.  And in 
> that case, it could perhaps be used as a transition.
>   
The type handlers making the callback to the base function, is the way
I've envisioned things working and to me seems like the best way of
doing things.

>   I still wonder how much that does make sense, as in that case, the type 
> callback would know what the legacy function is, and wouldn't really need a 
> baseclass mechanism to figure it out, simply because there is an old function is 
> a single function that would cover everything.
>   
Well, yes one wouldn't need the baseclass mechanism for it, however IMHO
we should have such a suggested baseclass mechanism for uses other than
legacy function handling, and adding more special cases in the
ob_apply() type functions doesn't seem as appealing to me as using the
generic baseclass system such as that, where references to the legacy
function are in one block of code instead of spread across multiple
functions.

> <snip>
>   At some level, all the drop stuff eventually calls the same function, and in 
> that function, it can check for various attributes (god given equipment, etc).
>
> <snip>
>
>   Yes, all of this should go through a common code path, but saying those checks 
> should be in the 'command' code may not be the right answer, depending on what 
> the command code is defined as.
What I'm saying, is that 'character initiated' actions should be
separated from 'raw actions'. In particular, in some way such that all
'character initiated' calls follow a common code path that only applies
to the 'character initiated' aspects. I was thinking that only 'raw
actions' should be in the callback system. Though now that I think about
it, one could potentially add in a central location, pl_ob_apply(),
pl_ob_drop() and similar functions, which would do 'character initiated'
aspects then run the callback (ob_apply() and ob_drop, etc.).

Alex Schultz