[CF-Devel] CF object structure (was RE: brief introduction)

[Andreas Vogl]

Mark W. wrote:

>
     
      I don't have all the gory details.  But I envision something like:
     
     >
     
     
     >
     
      struct object {
     
     >
     
     	object *next, *prev, *next_active, *prev_active, *above, *below;
     
     >
     
     	mapstruct *map;
     
     >
     
     	int x,y;
     
     >
     
     	/* ie, have all the pointers that all objects, no matter what their
     
     purpose,
>
     
     	 need to have.
     
     >
     
     	*/
     
     >
     
     	union type {
     
     >
     
     	    items *items;
     
     >
     
     	    monster    *monster;
     
     >
     
     	    background *background;
     
     >
     
     	} type_ptr;
     
     >
     
     	int type;
     
     >
     
      }
     
     
The approach with union types does not seem satisfying to me.
I mean, sure it would have a few benefits over the current structure,
but is it really worth the while - say: the work?
When I imagine the implementation of this scheme, I get the feeling
that the code won't get any shorter nor any better structured.
We'de always have to handle down long lines of pointers everywhere,
always doublechecking if the ones we want are actually defined.
This means a lot of ways to segfault and *very* long expressions to
mess with. Imagine the whole code looking like this:

   tmp_object.type.item.subtype.equippable.fire_resistance =
   new_object.type.player.blabla ...etc;

If we just extend the map-editor to give the user a true idea how
to work with the arch attributes, at least the multiple usage of
attributes (like "last_sp") won't be so troublesome anymore. The
editor can put a nice GUI-mask over it with appropriate names and
good hints.

However, if the redo of the object-structure is to be done, I would
choose to go the object-oriented/C++ way. A proper inheritance-based
class hirarchy seems the only way for a *real* improvement IMHO.
Like this:

class object { ... }
class item: public object { ... }
class equippable: public item { ... }

I don't want to go deep into explaining the numerous advantages
of object-oriented programming and inheritance models, assuming
that most of you know about it.
But in short: We'd have perfectly structured and eays-to-read code.

Well, I know: Probably most of you will now think that's crazy
because it's way too much work. But if it is - Then maybe we should
just stick to what we've got and try to make the best out of it?


Andreas V.