[crossfire] 2.0 object-type refactoring

[Mark Wedel]

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.

  per arch/per object I think gets into some other issues.  Registering them 
isn't hard - the more serious question is if those callbacks are in addition to 
the ones normally for that object, or are instead (or does something control 
that?).  But that is a future discussion.

  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.

> 
>> <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.

  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

  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.