Enfiladealigner (was: Re: [Gzz] Ids)

[Benja Fallenstein]

Tuomas Lukka wrote:

> On another note: I'm deprecating the *Space constructors that
> take an enfiladealigner: I already said here that Space should not
> do anything with an enfiladealigner, as the implementation is too
> ill-defined. I'd like to retain the gzz core APIs such that they could
> be formally defined and justified.
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.

Maybe a different subinterface of CellTexter (could be in a different 
package) would be right?

> What would you think of gzz.fuzzy which would contain EnfiladeAligner
> and also all Merge code? This would be a package for the more intricate,
> less rigorous algorithms.
>  
Ok. StringSearcher should also go there.

By the way, StringSearcher needs to be rethought: we need to be able to 
update mappings, because cells' text can change. How about making the 
data it operates on a mapping from keys to one String per key, and then 
make the op searching for a String and returning all keys that are a 
good match?

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.

-b.