On Wed, 26 Apr 2006, Ethan Bradford wrote:
On 4/26/06, Kevin Atkinson <address@hidden> wrote:
On Wed, 26 Apr 2006, Kevin Atkinson wrote:
On Tue, 25 Apr 2006, Ethan Bradford wrote:
So I should clone common/string_enumeration.* and string_list.* with
"suggestion" instead of string, right?
That sounds reasonable.
Those files are in the common
directory. Do the suggestion list/enumeration utilities belong
there,
or
closer to modules/speller/default /suggest.cpp?
No they should still be in common since it will become part of the
public
interface which is not directly related to the current speller module.
(Ie a
different speller modules, if one was every written, would likely want
to
them).
I should also add, that if the files are automatically generated you
should modify "auto/mk-src.in" if possible. Just use the other entries
as
example it should be easy to figure out. If it looks like mk-src won't
do what you want than let me know.
I found and modified auto/mk-src.in; it's working like a champ!
The SuggestionList class it creates is abstract, I'm thinking I want
the
implementation in common/, since there's likely to be only one kind of
SuggestionList, and as such, I'm thinking to override the produced
suggestion_list.hpp with a concrete implementation, as is done for
string_list.hpp. I'm leaning towards keeping the abstract class for
SuggestionEnumeration, and defining (also in common/)
SuggestionListEnumeration as a concrete implementation working on a
suggestion list.
SuggestionListEnumeration? What exactly will that do?
I suggest you just copy what is done with String{List,Enumeration} But
instead of returning a "const char *" return a "const Suggestion *"
object. Suggestion should be a structure something like
struct Suggestion {
const char * word;
size_t word_size;
float score;
};