[sword-devel] Strange option filters

[Jaak Ristioja]

On 27.10.2016 22:54, Jaak Ristioja wrote:
> 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?

Bump.