Re: Enfiladealigner (was: Re: [Gzz] Ids)

[Benja Fallenstein]

Tuomas Lukka wrote:

> On Mon, Aug 19, 2002 at 09:47:55PM +0200, Benja Fallenstein wrote:
>  
>
> > Hm. While I do understand that, I also feel that enfilade aligning 
> > should in fact be a part of the core API, with the following functions 
> > in CellTexter:
> >
> > exportText(Cell)
> > updateText(Cell, String)
> >
> > This is because I would like the client not to be dependent on 
> > VStreamTexter etc. here: a simple string-based cell texter could 
> > implement these methods in a terribly simple way.
>
> Well... I don't know. We might actually use fake spans there.
Where?

The point is: Our client's functionality should work with any backend 
implementation that is capable of delivering some given level of 
functionality-- meaning, it *should* work with a non-span implementation 
if someone wants to write one. The point is leaving the door open for 
innovation-- someone may want to create a bridge that uses some other 
ZZ, e.g. the perl impl, as the backend. Someone may even want to create 
a cell texter that works still totally different... and they should be 
able to try it without rewriting the complete client package (as long as 
that compatibility doesn't cost us too much).

> But either way, aligner represents a complicated functionality that has 
> a lot of *policy* embedded into it as assumptions and should not be set
> on a space-wide way. 
>
> What you want to happen depends on where you are.
Yes, I know... it's a two-dimensional problem: You may want different 
implementations at different times, but implementations also depend on 
the implementation of the space.

Maybe have a factory of strategies connected with the space, something a 
bit like Sun's security providers? Hmmm...

> I'm all for creating new classes for the different policies and using
> them statically:
>
>         AlignedTexter.getText(cell)
>         AlignedTexter.setText(cell, string)
>
> or dynamically. 
Definitely dynamically. I believe it is very wrong to embed the choice 
of strategy statically in the client code. Of course that's the same 
reason I don't like,

a = AlignedTexter(space)
a.getText(cell)

If the strategy is set when creating the space, at least there is some 
choice there, but I agree it is a bad place for it.

> > I'd also like to define the result of a StringSearcher match always to 
> > be ordered (two consecutive searches return the same order of items), 
> > because I'd like to be able to step through the different matches with 
> > e.g. the up/down keys.
>
> Sorted could be very good.
>  
Ok. But StringSearcher does have a similar problem as above-- the cell 
texter must know the StringSearcher, yet we'd like to have different 
strategies at our disposal. Can we solve this somehow? Recreating the 
table each time we enter another character of the search string is 
certainly not an option.

-b.