On Thu, 27 Apr 2006, Ethan Bradford wrote:
> On 4/27/06, Kevin Atkinson <address@hidden> wrote:
>>
>> 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;
>> };
>>
>
> But StringEnumeration is an abstract class, with concrete implementations
> attached to various things to enumerate through: DictStringEnumeration,
> IstreamEnumeration, StringListEnumeration. SuggestionListEnumeration would
> be like StringListEnumeration: a concrete class for SuggestionEnumeration
> whose target data is a SuggestionList.
Sorry, I though StringEnumeration had a concrete implantation. Since
Suggestion Enumeration would have only one logical implementation it
doesn't make much sense to make it an abstract class. None of my C++
interface is meant to be used by external programs, so if it becomes
necessary to make it into an abstract class that can be done latter.
However, I don't have any strong objections to making
Suggestion Enumeration an abstract class.
All the various indirection in the data structures confuses me, though
I think I've settled in to a proposal for the internal architecture.
(1) I leave the SuggestionList and SuggestionEnumeration virtual.
(2) In suggest.cpp, I rename the SuggestionList class to SuggestList
(so as not to collide with the new acommon::SuggestionList).
(3) I add a vector of Suggestions to SuggestionListImpl (renamed
SuggestListImpl), parallel to the vector of Strings in the field
"suggestions"; I can call it "scored_suggestions".
(4) When Speller->suggest is called, it calculates
scored_suggestions, then copies that into suggestions and continues as
now.
(5) I create a derived class of (new) SuggestionList in suggest.cpp which contains SuggestListImpl, called SuggestionListImpl.
(6) Its elements() call returns a SuggestionEnumeration pointing to the
the new scored_suggestions field of its SuggestionListImpl.
-- I hope this can use MakeEnumeration from enumeration.hpp.
(7) A new method in Speller (maybe "scored_suggest") returns a new
SuggestionList initialized with code common to the existing suggest
method.
An option is to store only the vector of Suggestion and make the
enumerator which returns string suggestions know about the Suggestion
structure, extracting the string it needs from that. I don't
favor that because it's extra work and doesn't save much space.
Any suggestions or corrections?