[Dynamite] wiki back (hurray)

[Ian Holmes]

(long mail, feel free to read at your leisure)

On Wed, 22 Mar 2000, Ewan Birney wrote:

> 
> I think we can consider extending IDL to fit our needs - ie,
> coming up with (a limited number) of templates like sequence<>.
> 
> As long as we have well defined ways of mapping things to vanilla
> (apologies ian)

no apologies necessary - i am fully aware that there is an army of
stroustrup fanatics trained in martial arts who would kick my head for
doing the idlstubs program. (not to mention the java snowboarders)

> IDL then I think this is better than relying on
> conventions. (eg, for set<something> and keyvalue<something>).
> 
> This is what mozilla has done with their PIDL system (they extended the
> IDL).

It sounds great. I think this is where the action is, but I can't find it
on the web... got a url?

I am up for doing templates like this, and just copying the STL at first,
picking templates that can be "instantly" mapped to C using our
IDL->Euclid->GLib mappings.

A "fat" STL set would be:

EuclidVector(X)                    sequence<X>   (unfortunate name)
EuclidPair(X,Y)                    struct { X first; Y second; }
EuclidSet(X,cmp_object)            balanced tree of pointers to X's
EuclidMultiset(X,cmp_object)       balanced tree of X array pointers
EuclidMap(K,V,key_cmp_object)      maps K's to KV's (tree of K's to pair<K,V>'s; so, this is effectively a set<pair<K,V>> indexed by K-comparison)
EuclidMultimap(K,V,key_cmp_method) maps K's to arrays of KV's

...and maybe...

EuclidList(X)                      doubly linked list
EuclidSList(X)                     singly linked list


If we provide all the requisite methods for sequence<> on these, with the
element type for maps being pair<K,V> (nb sequence<> implicitly provides
random access to its contents, so we offer this via a data() method that
checks a "dirty" flag and returns a pointer to a protected array with an N
log(N) hit if it needs to "clean up"), then we will have reimplemented the
STL - I don't plan to do that straight off ;) but I do think that as a
general rule we should stick to STL-like nomenclature if we are going to
extend things (even gradually) because this is C-like and the STL is the
closest C has to a generic programming standard.

We should always be able to compile our IDL with orbit-idl and have a
well-defined mapping to sequence<> or struct for all generic programming
objects. So we define macros in the IDL that idlstubs ignores eg

	#define EuclidPairDecl(X,Y)     struct X_pair_Y { X first; Y second; };
        /* EuclidSetDecl, EuclidMapDecl... */

	#define EuclidPair(X,Y)         X_pair_Y
	#define EuclidSet(X,CMP)        sequence<X>
	#define EuclidMap(K,V,CMP)      sequence<EuclidPair(K,V)>

...or even (better?) #define these macros to be interfaces with the
appropriate methods.

In fact it would be more efficient to use multiline macros in the C output
too, for a lot of the reference counting code that's already there as well
as for new stuff. I *guess* most C compilers can cope with multiple nested
macros and so on but I don't want this to be a portability issue later on.

> 
> Feeling out of the loop as I can't cvode on it. Will try to clear my
> coding desk as fast as possible to be able to work on this.
> 

It's OK, this is all early days, we're just talking guts design... all
I've done so far is fleshed out the remarkably succinct and consistent
mapping you laid out.

I propose that (at some point) we start a TestZone on the wiki where we
document & automate all the tests we intend the package to fulfil,
including microtests from the very beginning, like compiling dummy objects
on a Sun or a windows box or a maspar(!) or a cray (I do have access to
a cray T3E..)

or something like that anyway - need to read up more about this XP-wiki
shit eg www.xpdeveloper.com (Oli's bunch's site) - I definitely want to go
to one of their meetings in London some time.

But - you are not out of the loop, it is just that the loop is (from a
certain pov) a bit mundane because (imo) the best thing for us to do is
to suck in all the best bits of GLib and STL, as and when we need them to
get things working. So if people don't mind following this 

I may leave this for a bit anyway, I have a paper to write & some RNA
folding to do as well!

I.

> 
> 
> -----------------------------------------------------------------
> Ewan Birney. Mobile: +44 (0)7970 151230
> <birney@ebi.ac.uk>
> -----------------------------------------------------------------
> 
> 
> _______________________________________________
> Dynamite mailing list  -  Dynamite@bioperl.org
> http://www.bioperl.org/mailman/listinfo/dynamite
>