[crossfire] 2.0 object-type refactoring

[Alex Schultz]

Mark Wedel wrote:
> <snip>
>   In that mode, I still think it would be easy to do an object type at a time - 
> you'd have something like:
>
>   ob_apply()
> {
>    if (we have callback) do_callback()
>   else call_old_apply_function()
> }
>
>   type of thing.
>   
Yes, I agree and do now believe that doing it one-type-at-a-time would
work better overall than one-callback-type-at-a-time. The way you say
above is about what I'm thinking.

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.

> <snip>
>   The previous example I had was about applying unpaid objects.  I can't think 
> of any case where that should be allowed, and if there was some specific reason, 
> I think a flag on the object should control that, and not object type (as 
> presumably, that object would have some behavior like existing objects).  I 
> think it is cleaner to have it like:
> <snip>
>
>   (another different case here is dropping of damned/cursed objects - regardless 
> of type, that shouldn't be allowed save for something special (DM))
>   
Well, IMHO those dropping and unpaid restrictions should either be in
the command code, or give the callback an 'override' parameter, because
of the "save for something special" cases. Either works for me, but I am
inclined against the 'override' parameter as it IMHO creates unnecessary
complexity.

Alex Schultz