[crossfire] 2.0 object-type refactoring

[Alex Schultz]

Mark Wedel wrote:
> Alex Schultz wrote:
>   
>> Well, my original thinking, was that if I were to do it by completing an
>> object type, instead of a callback type, then it would be somewhat of a
>> pain to make it redirect to legacy methods for other object types not
>> yet implemented in the new system. What's your view on that issue?
>>     
>
>   Some of it depends on how this is done.
>
>   If you replaced the specific calls to apply, drop, etc as they are sprinkled 
> throughout the code, then doing one type of function is easier.
>
>   However, what I was thinking is those functions would still exist, but instead 
> of the case statements they have now, they would have something like:
>
>   if (callback_Exists_for_this_type) do_callback()
>   else { do switch statement}
>
>   In that model, doing a few types at a time is easier to do.
>
>   I also think you still want to have common top level/generic functions so that 
> you can have some common code.
>   
Well, the way I was thinking of doing it, would be to replace specific
calls to apply, drop, etc as they are sprinkled throughout the code, and
keep common code such as you say, in a "common" subdirectory of the
types directory, and then have the callback called by ob_apply(), call
something like ob_apply_common() at the start of it's code.
IMHO, with this method, the best way to handle legacy non-separated
logic would be to move that legacy logic to the "types/common"
subdirectory, and set it up so ob_apply() and such will call that if it
can't find a callback registered for the type.

> <snip>
>   A better case here may be something like examine/describe item, where many 
> objects may have some specific/unique properties, but many also have common 
> properties (value, cursed, applied, etc).
>   
Well, I'd be inclined to say this could follow the same model rather
well. Simply have examine/describe as a callback like any others. The
callback at it's option can call code stored in something like
types/common/describe.c for behavior common to multiple types (get the
string for generic properties of it). If ob_describe() finds no
callback, it falls back to a generic function in types/common/describe.c
IMHO this model allows the most flexibility for cases where we might
want the 'common' behavior overridden for a type. Also I believe this
model would be very valuable if per-object or per-arch hooks are
implemented and the plugin system given access to that.

>   Other thought not related to the above:
> Given this is a major restructure, would it make sense to collapse/redo some of 
> the types, particularly the equipable equipment?
IMHO This should be done as well, though one question is: would it be
worth completely redoing the type numbers and converting all of the
maps/arches? Or should we try to keep the numbers the same where
possible, and have the loader change type values that were collapsed to
the new value?

Alex Schultz