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. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire