[Dynamite] Is this working now then?

Ewan Birney birney@ebi.ac.uk
Fri, 3 Mar 2000 14:27:01 +0000 (GMT)


Ok. I guess I should start with a post about the
Dynamite-Telegraph code architecture:

(all points debate-able - just need to settle them).

Main points:

a) using IDL definitions of the main objects, but with a by hand
   translation to C header files.

   module in IDL -> "a module" (ie a namespace)

   interface in IDL -> "a object"


b) All the main object files have two header files:

   object.h
   object_internal.h

(could be object_external.h and object_internal.h)

object.h must only contain method declarations and sizeless
datatypes, eg

typedef struct SomeObject_str * SomeObject;

By having this split we can be guarenteed by the C compiler
that the code can be wrapped cleanly to any other language (nice).


NB - this means for some objects we will have to write get/set
accessors for simple data fields. C'est la vie.

object_internal.h has the size of structures


  object_internal.h must include object.h


We use the standard include guards

#ifndef MODULE_OBJECT_HEADER
#define MODULE_OBJECT_HEADER

#endif


c) Each module in IDL -> one directory in the source code, and
   one library to link to.

d) objects between modules are only allowed to include each other object.h
   and not object_internal.h

   NB - this might force us to almalagmate say the sequence object
   into the modules - we have a tough decision here:

	a) sequence object shared (internally) across all the code,
so effectively one big module (yuk)

	b) sequence object as a separate module (yeah!) but then 
we need methods always to access it, meaning possibly internal
sequence objects in some modules (yuk)

	c) "special rules" for the sequence object to allow
its internal interface to be exposed even across modules. (yuk).


I have to admit, I favour (b)




e) object inside one module *are* allowed to include each other's
   object_internal.h if so wished.

f) the .c files should only include the object_internal.c


g) Variable names:

   namespace_MixedCaseLetters for objects

   namespace_ObjectName_method for methods

   namespace_MixedCaseLetters_str for structures

   method_vf for virtual function slots when required
   for polymorphism.

additional underscores in methods allowed

? __ (double underscore) before method to indicate private functions
(possibly bad).



h) Standard methods on every object:

(ns = namespace)

   ns_Object_ref(); increases the reference count on the object

   ns_Object_unref(); decreates teh reference count (free's the object).

   ns_Object_debug_dump(FILE*); provides a debugging info for teh object
                                (????)

(debug_dump - far more useful than you might think at first, in
particular debugging through a corba/other language interface).


i) use glib for errors.



Rip this to shreds guys and come back with a better solution ;)

















-----------------------------------------------------------------
Ewan Birney. Mobile: +44 (0)7970 151230
<birney@ebi.ac.uk>
-----------------------------------------------------------------