[sword-devel] VerseKey decoupling was Re: proposed changes to VerseKey

[Daniel Glassey]

On 20/06/05, Lynn Allan <l_d_allan at adelphia.net> wrote:
> Daniel,
> 
> Glad to see you are doing some rethinking / refactoring of VerseKey.
> Thanks. The getChaptersInBook and getVersesInChapter will be a welcome
> replacement for
> setPosition(POS_MAXVERSE) and
> setPosition(POS_MAXCHAPTER)
> 
> While you have "Vulcan mind-meld" with the VerseKey class, perhaps you
> could consider some repartitioning /decoupling of the class itself. My
> understanding as I look at the code, is that VerseKey references
> localemgr, which references swmgr, which references swmodule, and then
> it "spreads out" further and further with "octopus tentacles" so that
> there is an enormous amount of class coupling that seems less than
> what was intended for VerseKey.
> 
> My impression is that the purpose of VerseKey itself is rather modest
> ... to provide KJV versification so an application can get the
> information that there are 50 chapters in Genesis, and that Gen 1:31
> is the last verse in Gen 1, for example.  Also, it can "work very
> closely with" rawtext, rawverse, zverse, and ztext to "unpack" the
> offsets and lengths of the actual verses in the compressed and
> uncompressed files.
> 
> My limited experience with building some of the test examples in the
> test subdirectory is that if you have VerseKey.h, your code will end
> up needing to get such seemingly unrelated classes as osis to be able
> to link. Is that amount of class coupling necessary? Perhaps now is a
> reasonable time to consider some class decoupling?
 
> My impression is that there could be a class from which the current
> VerseKey "is-a" derived, which is concerned strictly with
> versification?  Or VerseKey "has-a" member variable which is a class
> which accomplishes this functionality?
> 
> Perhaps a goal to shoot for ... VerseKey is decoupled enough such that
> with only rawtext, rawverse, zverse, and ztext, it can be
> compiled/linked and still accomplish a significant amount of diatheke
> functionality ... something that might be called "MiniDiatheke"?

Thanks Lynn.
These are very good ideas in general - decoupling.

I don't think that VerseKey is the big culprit. It only pulls in
SWLocale and SWConfig which are necessary for i18n of books.
otoh It might be good to have a base class for just default locale
(en_US I guess) if you want a simpler app.

The big problem is SWMgr. If you link it then you pull in just about everything.
To be able to read any module then you need all the filters. They are
the biggest part of code.
It ought to be possible to only link in the filters you really want if
you are static linking. Could you give an example of a small testapp
that has the problem and what kind of things it links in please?

Regards,
Daniel