[sword-devel] C++ question

[Joachim Ansorg]

Thank you for the answer, Troy!

> > We want to derive our classes directly from SWModule, but IMHO this is
> > not possible. But perhaps I think this because I don't know C++ very
> > well.
>
> IMHO, I don't believe this is the best design.  Let me explain why:
>
> 	o I think in Torsten's thoughts on the original backend, he wanted to
> allow other engines besides sword.  Now obviously, I think we'll be able
> to give you everything you need :), but if you extend SWModule, you will
> not have the option to use others.

I know that we shoulsupport more than one backend. But using a base for all 
backends is bad (some modules are not key bases, but our base class 
CModuleInfo was key based). So we think the best design is to have some base 
classes like CModuleInfo and CKey, but they do only contain the functions 
used by all modules you can think of.
The classes derived from CModuleInfo will be handled individually (e.g. one 
presenter for one special module). The searchdialog does also depend on the 
module type (sermons and maps need other search interfaces).

> 	o  SWMgr is designed to give out 'sets' of base SWModule's.   It
> handles creating the correct SWModule derivitate for the frontend
> developer, based upon each module's configuration.  This 'common' base
> class of functionality is SWModule, or possibly (logically) one level
> shallower, SWText, SWCom, or SWLD (known by SWModule::Type()).

Now we use member variables, so it does not matter.

> 	o  If you want to augment the COMMON functionality of what a 'MODULE'
> does, the correct place to do it would be IN SWModule (or SWText, ...,
> if they are more specific to a module type.)

We simplified the things in our classes (e.g. getBooks() or 
getChapterCount(int book), getVerseCount(int book, int chapter)). I think 
it's bad to put these functions into SWModule.
We also used Qt's classes to support Unicode at least in BibleTime.

Thank you Troy for the help!

--Joachim
--Joachim