[crossfire] 2.0 object-type refactoring

[Mark Wedel]

Alex Schultz wrote:
> 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:

  The only issue with using the baseclass for fallbacks of old code is that the 
calling structure has to be the same.

  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.

  I also think more thought/discussion on these different callback mechanisms 
need to be thought out.  The idea of per object callbacks have also been 
mentioned.  How all of these interact need to be clearly defined.

  For example, is the BASECLASS callback always made, regardless of anything 
else in the object?  Is it only made if if there isn't a specific callback 
registered, etc?  Depending which is done, that is a major difference, and has 
to be reflected in the code that is written.

  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.

  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.


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

  But how do you reasonably do that, if you don't know what overrides are needed?

  Only thing I can really think of is to just have an integer parameter that you 
pass it, that could contain various values (bitmasked) that could be added extended.

  The main problem there is that if some override is added, there may be 20 
callbacks you need to add code to.  Which is why having that in the top level 
handler makes it easier - only one place that the code needs to be written.

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

  It depends on how you define the command code in this context.

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

  However, there are probably at least 4 paths to get to that function, 
depending on how the object is dropped.

  Picking stuff up would probably be more so if you think about it.  There is 
the automatic pickup modes, there is mouse control (right click), there is 
keyboard control.  You can also get objects indirectly added to your inventory 
(being hit by an arrow).  Using shops can sort of change inventory (coins added 
to make change, etc).

  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.