tchize wrote:
Le Mercredi 18 Janvier 2006 07:30, Mark Wedel a écrit :
However, I think if you start grouping all that stuff together, you start
loosing some of the advantages.
Depends once again on the size of things you regroup and how much they have in
common. if you start making 80 modules for what is current server i think you
also miss the point on managability :)
Right, but you have to keep this in mind.
For example, there are probably about 100 different object types out there.
So if we take the module example, you either get 100 different modules for all
those objects, or a fairly big/complex module that handles those 100 different
object types.
It is unclear to me right now which is the better case.
This gets especially messy if say 10 object types are complex enough that they
really should be in their own module. So now you have those 10 separate modules
+ common module for other 90 types. This then starts to get away from making
things easy to find (is it in the common module, or one of those other 10)
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.
You said it, it's the poor man version ;)
If we modularize things, it is a good thing to have a plugin part in it. Even
if some of things currently in core could be done as module not plugins (like
let's say, binding a libCrossfireRandomMap.a at link time) you will probably
get into the case when someone want to add new behaviours in plugins.
True. However, I'd think that to do this by true plugins, the
objects/archetypes have to get updated, eg, hooks added for describe item, apply
item, etc. My poor mans version avoids that.
Another question is whether a plugin can call another plugin - that in itself
could perhaps limit the ability of some things to be in plugins.
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
