[Dynamite] Is this working now then?

[Ian Holmes]

On Sat, 4 Mar 2000, Ewan Birney wrote:

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

OK.

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

This is pretty much exactly why I had misgivings about the sequence object
being top-heavy. Do you not think that this all indicates a lightweight
Sequence structure (name + data only) rather than a bloated design that
forces us to maul the object model to make it work.

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

Ian