[Dynamite] Is this working now then?

[Ian Holmes]

On Fri, 3 Mar 2000, Ewan Birney wrote:

> Main points:
> 
> a) using IDL definitions of the main objects, but with a by hand

Could also be semi-automatic?

>    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

Why not enforce this even more strongly, for objects in the same module
too?

>    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)

Why is any of this necessary? The sequence object has a seq attribute.
Isn't that all the other objects need?

> 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.

OK

> additional underscores in methods allowed
>
> ? __ (double underscore) before method to indicate private functions
> (possibly bad).

Bad -- double underscores are always being reserved for compilers and the
like. Try "pf" instead?

> 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).

Is this taking the place of new & delete?

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

This shouldn't be a standard, but most objects will end up having it
anyway.

> 
> (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.
> 

Examples please?

Ian

> 
> 
> Rip this to shreds guys and come back with a better solution ;)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----------------------------------------------------------------
> Ewan Birney. Mobile: +44 (0)7970 151230
> <birney@ebi.ac.uk>
> -----------------------------------------------------------------
> 
> 
> _______________________________________________
> Dynamite mailing list  -  Dynamite@bioperl.org
> http://www.bioperl.org/mailman/listinfo/dynamite
>