[libvoikko] Test cases for libvoikko/HFST needed
hatapitk at iki.fi
Wed Jan 20 16:57:41 EET 2010
On Wednesday 20 January 2010, Flammie Pirinen wrote:
> Yes that is certainly current state of the things, only guarantee in
> current library is that it provides almost same function signatures
> for both back ends. Our svn contains a reformulation in object
> oriented terms that provides framework for inclusion of more backends,
> but it seemingly does not escape the requirement of including headers
> of underlying libraries as implementation classes contain private
> members of data structures from the backends.
I looked at hfst3_proposition/HfstTransducer.h and it seems like most if not
all problematic data members are protected members of HfstTransducer. These
need to be declared in the header only if HfstTransducer objects are meant to
be created directly in the client code which should not be necessary.
You could just push all the protected stuff to a new class HfstTransducerImpl
and derive that from an abstract base class HfstTransducer which would contain
only the public methods.
Then you will need to publish a factory function/method in HfstTransducer.h
that will return a pointer to a new HfstTransducer object. Now
HfstTransducer.h no longer needs to include any implementation specific
headers anymore, they are only needed in HfstTransducerImpl.h which will be a
More information about the Libvoikko