[sc34wg3] Re: Going beyond SIPs?

[Robert Barta]

On Fri, Sep 03, 2004 at 09:53:02AM +0200, Jan Algermissen wrote:
> > What can we do to press you to come forward with a description for
> > this? Bribe? Or would threats work? :-)
> 
> The problem is that you would not understand it, unless I explain quite
> a bit of my implementation approach. Unfortunately I don't have the 
> time to do all that typing right now.

I understand that only too well, but then the risk is that your ideas
will never be picked up by others.

> The basic story is, that TMTK totally decouples value types and
> their storage implementations from the core engine.

That is very similar to my Perl code here, but....

> Value types are basically classes that are constrained to at least
> provide a minimal set of methods (the ones needed by the core) and
> value stores are specialized storage implementations that also need
> to implement a certain interface. The value stores really are doing
> the difficult stuff and that is to provide reasonably fast
> implementations of the various functions called on them (primarily
> during merging).

...I have chosen the abstraction layer not to be at the "value level",
but on the map level itself. Actually, the path language is at the
abstraction layer (I use path expressions for reading and writing).
With that I can have completely virtual maps, not actually carrying
any content themselves.

> Example: During merging, there are *LOTS* of invocations of the not_disjoint(v1,v2)
> operator on values of type 'locator-set'. More precisely, scans are opened on the
> value store in the form
> 
> scan = value_store.openScan(value1,operator,args)
> while( scan.hasMore() )
> 	value2 = scan.next()
> 
> so, given operator to be "not_disjoint", this scan will find all values that are
> not disjoint with value1

That is something I was not sure whether this works as soon as the
maps get bigger. Lotta calls here. I preferred to have a method
"consolidate" at the map level. 

> The burdon to implement this operator in O(log(N)) is on the value store
> implementation (where else could it be, given that arbitrary value types
> are allowed).
> 
> That's basically the hot spot.

I bet, yes.

I here only allow scalars native in a map. Makes life simpler.

\rho