[sword-devel] Strange option filters
Jaak Ristioja
jaak at ristioja.ee
Thu Oct 27 12:54:39 MST 2016
Hi!
While refactoring some option filters code for Sword++ I found two
strange option filters, GreekLexAttribs and PapyriPlain which inherit
from SWOptionFilter and use SWOptionFilter::SWOptionFilter(). This
behavior was introduced in SVN 1864:
commit bdc81675088ca687338ca29acef6c384710b6bcf
Author: scribe <scribe at bcd7d363-81e1-0310-97ec-a550e20fc99c>
Date: Sun Nov 20 06:06:40 2005 +0000
Cleaned up headers to remove unnecessary includes
git-svn-id: https://crosswire.org/svn/sword/trunk@1864
bcd7d363-81e1-0310-97ec-a550e20fc99c
Neither of those classes override any of the SWOptionFilter methods for
options, hence the effects of SWOptionFilter::SWOptionFilter() are
permanent for instances of these classes. This means that
getOptionName() returns "" for both of these classes. This looks as if
it could cause problems for SWMgr which seems to rely on these being
unique strings for each class (e.g. in SWMgr::AddGlobalOptions). So its
rather confusing.
Some SWMgr methods test whether getOptionName() returns NULL. I couldn't
find any conclusive hints in Sword source code to describe the rationale
of it returning NULL. None of the Sword classes themselves seem to
return NULL themselves. So the only possible way for getOptionName() to
return NULL is for some child class overriding getOptionName() or
overwriting that protected field. Before SVN 1864 these virtual methods
were also part of SWFilter and their defaults returned NULL (well, 0).
Can someone please enlighten me about this code?
Thanks!
Many blessings,
Jaak
PS: Should these two classes actually be simple On/Off-style option
filters and properly call the other SWOptionFilter constructor?
More information about the sword-devel
mailing list