[crossfire] 2.0 object-type refactoring

[Alex Schultz]

Mark Wedel wrote:
> Alex Schultz wrote:
>   
>> Another thought, perhaps instead of the "else" though, we could use the
>> "BASECLASS" via another ob_methods structure as mentioned in a different
>> mail, to implement the falling back to the old function. Not only is it
>> well suited to falling back to the old function, it IMHO might prove a
>> useful system to have in place for after the conversion is complete,
>> particularly once getting into per-arch and per-object ones with plugin
>> support.
>>     
>
>   I personally wouldn't  be overly concerned about neatness while in the 
> transition.  After all, it is a transition, and will eventually go away, so 
> being too concerned about how it work doesn't make tons of sense.
> <snip>
>   I'd think for generic callbacks, it depends on its purpose.  For the 
> transition purpose, I think it'd have to fallback to a single function for all 
> object types.  I'd personally rather just see a call like 'apply_fallback()' 
> type of thing vs a 'BASECLASS[APPLY]()' type of thing - if there is only 1 
> function for each type, it is easier to follow the code if you see exactly what 
> the function is, and don't have to go look at BASECLASS to see what it is doing, 
> etc.
>   
Well, I'm thinking that we do have a "BASECLASS", we might as well use
it for transitional fallbacks, OR better yet make a "TRANSITONCLASS" or
something, which the "BASECLASS" is based on. I would say that would be
just as easy to follow as things like apply_fallback() and in fact on
can make names like that a convention for transitional functions.
Also, fallbacks could potentially be handled very easily and generically
in the functions like ob_apply(), such as in this example:

int ob_apply(object *ob, object *pl) {
    ob_methods *methods;
    for (methods = type_methods[ob->type]; methods; methods =
methods->fallback)
        if (methods->apply)
            return methods->apply(ob, pl);
    return 0;
}

Also, things like the generic callback for 'drop', that generic code can
be moved straight away to the "BASECLASS", and makes having the separate
"TRANSITIONCLASS" helpful for organization to show the difference
between purely transitional functions and other generic callbacks.
Eventually one could simply remove "TRANSITONCLASS" and the framework
would still be useful for "BASECLASS" and other things. Sure, one could
put the calls to the generic callbacks straight into ob_apply, however
due to the repeated code for calling callbacks, I would find it nicer to
avoid differences in their code beyond what is necessary.

>   I was thinking overrride would be determined by the object (or person) using 
> the objects themselves.
>
>   In the curse example, you could check the person unapplying it, and if the 
> WIZ, let them do so.  Sure, you could pass in parameters for that, but I doubt 
> that is necessary
>   
Well, the thing is, I believe it would be beneficial to have the extra
flexibility of being able to make these calls and have the caller make
overrides for reasons other than WIZ and such. It's not that it's
currently needed, but I'd prefer to leave the opportunities for such
open if reasonably possible.

>   In all these cases, that code will be someplace - it is just a question of where.
>
>   For some things, doing it in the command code isn't ideal, because there are 
> several ways for the command to be issued (some are processed by the client and 
> sent as lower level protocol commands in addition to having text commands the 
> player an use, etc) - in those cases, you want the check code in the function 
> all of those call so it is in one place, not 3.
Well, IMHO if the command code doesn't have a unified method for calling
something like "apply" or "drop", then perhaps that needs to be cleaned
up, so putting those checks in the command code would be practical.

Alex Schultz