Handling Netherlands' bankId

[Prasun Kumar]

Hi Thomas,
Thanks for answering.

> I think turning the member var into a std::string is a viable solution.
> I scanned briefly over the source and found important use of the numeric
> variant only in the "German" sections of it.
>

I thought that was the better idea too. Initially, I was looking for
alternate ways because of the API design
principles of avoiding modifications in a public API. However, I think if
the ctors and other methods are
adjusted accordingly, it would not impact anyone dependent on the API.

Thanks for the insight.
Prasun

On Mon, 17 Aug 2020 at 11:50, Thomas Baumgart <thb at net-bembel.de> wrote:

> Hi Prasun,
>
> On Sonntag, 16. August 2020 07:31:03 CEST Prasun Kumar wrote:
>
> > Hi mentors,
> > The Record class has member 'bankId' of type unsigned long. However, in
> the
> > case of the Netherlands,
> > the bankID is a string due to which it is not working correctly. Should I
> > create another class named NL_Record
> > or something similar to handle Netherlands records? Alternatively, I
> could
> > just expand the 4 character bankID of
> > Netherlands into a long integer but that feels sort of like a hack and
> not
> > a solution.
> > Please let me know if there is a good way to handle this.
>
> I think turning the member var into a std::string is a viable solution.
> I scanned briefly over the source and found important use of the numeric
> variant only in the "German" sections of it. One thing I would not touch
> are
> the check functions, but they can be called with
>
>   return (iter2->second)(account, weight, accountId, atol(bankId));
>
> instead of
>
>   return (iter2->second)(account, weight, accountId, bankId);
>
> You may get rid of the ctor using the unsigned long as argument. Have not
> checked
> where it is used. A ctor providing a char* as argument already exists.
>
> One thing you need to change is the definition of the map containing
> pointers
> to the Records, which uses the ulong as key. This also needs to be changed
> and
> all the code using it, but should be straight forward.
>
> I would vote against using a special object (as in NL_Record).
>
> On a side note: using constructs like
>
>   if (country == "DE")
>   else if(country == "NL")
>   else if ...
>
> usually calls for a base class and some special derivatives and a set of
> virtual methods that do the specialization. But that change is maybe
> something for another project.
>
>
> Hope that helps.
>
> --
>
> Regards
>
> Thomas Baumgart
>
> https://www.signal.org/       Signal, the better WhatsApp
> -------------------------------------------------------------
> 'rm -rf' is a short-hand for 'read manual really fast'
> -------------------------------------------------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-finance-apps/attachments/20200817/5997bb99/attachment.htm>