[Dynamite] Is this working now then?

[Ewan Birney]

On Fri, 3 Mar 2000, Ian Holmes wrote:

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

Could be. Only if it is easy. I could hack orbit-idl but I don't
want to spend valuable coding time on "stupid" issues.

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

That is a suggestion, but not a requirement. By relaxing the requirement
inside a module (a module is basically one .so file/corba server) objects
can do funky memory reuse between them, point directly into each others
data structures if so wished.

It prevents functions inside one module from having to endless unpack
objects which they just made again during function calls. If we can do
it without any object_internal.h being included - this is much better.

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

Certain functions will want not to have to call methods repeatedly,
but will want to pass around the sequence as a set of datafields.

Let's go for separate modules and wait until we feel it is going wrong.


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