[libvoikko] Test cases for libvoikko/HFST needed

Harri Pitkänen 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 
private header.


More information about the Libvoikko mailing list