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

[Tuomas Lukka]

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

Not necessary: if it's like you said above, the text class can *check*
whether there's a VStreamTexter or not. Checking the type is a fast operation,
so I think this would be ok.

> >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 much rather have the user-interface components receive such a strategy
if necessary. That's where it belongs IMHO.

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

I don't think it's really a problem: database indices work exactly in 
this way: you can attach the indices anywhere and they get updated
either when you use them or when changes occur. All that needs to happen
is for the stringsearcher to get the updates e.g. through the deltaspace.


        Tuomas