[crossfire] Moving server towards a modularized system?

[Mark Wedel]

Gros wrote:
> It actually depends on the level of control you want to grant to the plugins. 
> The most extreme case would be to export all the functions currently in the 
> code - to do that, you'll have to provide a wrapper for each function you 
> want to export. That's a lot of functions, but let's not forget that a 
> significant part of those are only used by specific pieces of the code, so 
> the actual useful number is definitely lower than that by a significant 
> margin.

  One danger of providing wrappers to too many functions is danger of infinite 
recursive loops.  There is already that potential - the apply code always has 
such a check.

  But the danger could be that if module writers see a list of functions they 
can use, they may think it is safe to call it back at any time.  Not that is 
really any different than current code, but just a thought.

David Delbecq wrote:
> Nothing would prevent all those 'basic plugins' to be gathered together. 
> eg all kind of current exit in a module along with walls, grounds, name this 
> module 'basicLayout'
> anotherone for movment stuffs
> another module regrouping monster stuffs
> anotherone for all kind of traps 
> ...
> 
> Common lifecycle is 'add new feature in existing code, when it becomes lots of 
> line, move it to it's own module', unless of course you know from the start 
> it will contain lots of code  ;) 

  However, I think if you start grouping all that stuff together, you start 
loosing some of the advantages.

  I think there are also some limitations regarding the actual use of the shared 
libraries (modules) - for example, each one can only have one initialization 
function I believe, so if you have say 20 object types in one module, you'd have 
to mix all the code they need for initialization in one function (or have a list 
of the 20 function calls it makes).

> Well you put the finger on it. Adding a new object is generally adding a 2 
> lines code to apply which calls myObjectType_apply(). and same to describe, 
> sometimes, also for some same to move_object(). Damn this looks to me like 
> the pattern of registering listeners to some events :D

  But one could do that to some extent without plugins.

  You could for example set up something like:

struct object_type_description {
	functype	apply_func;
	functype	describe_func;
	functype	....
} object_actions[MAX_OBJECT_TYPE

  Then in the code, you could do things like:

  if (object_actions[op->type].apply_func)
	object_actions[op->type].apply_func(...)

  In a sense, a poor mans/specialized plugin.   You then just need one 
initialization function, but all the specialized code related to object type 
itself could be in one place.