[Kmymoney-devel] Review Request: Refactoring of matching a transaction-under-import

Alvaro Soliverez asoliverez at kde.org
Sun Dec 9 12:32:01 UTC 2012

Every dependency we bring into KMyMoney has a clear set of features and
benefits for the application (libGMP, libofx, aqbanking, etc.). In this
case, I only see a limited value for the developers. And it seems to me,
this  could be done the Qt way. Maybe the other way is more clear, but the
only real benefit is readability. Perhaps maintainability, but that's
offset by adding a new dependency.

I don't have the final word on this, but my vote is against adding boost as
a dependency. At least, until a real benefit for the application is shown.


On Sun, Dec 9, 2012 at 8:44 AM, Łukasz Maszczyński
<lukasz at maszczynski.net>wrote:

> Hi Alvaro, all,
> I chose to use boost::optional not just because it's convenient, but
> mainly because it makes my intentions clear. TransactionMatchFinder
> class will either find a matching transaction or not, that's what
> boost::optional is for - it either holds an object inside, or it
> doesn't. I can, of course, implement this using a pointer, and it
> would behave the same from functional point of view. Still, I believe
> boost::optional is a better choice here.
> To be honest, I don't really understand the last point you wanted to
> make by writing:
> > BTW, when the Transaction objects are created, they are initialized, so I
> > really don't see why boost::optional should be used here.
> Yes - Transaction objects are initialized when they're created, but I
> don't really see a connection to optional.
> I also understand your bad experience with some of boost's libraries -
> we had similar concerns regarding (not) using it where I work. On one
> hand there's a maintenance effort, if we allow "wrong" libraries
> (which tend to change their API, etc), but on the other hand why
> reinvent the wheel if boost already provides you with solutions to
> some basic problems. We solved that by creating two lists: blacklist
> (definitely prohibited modules), and whitelist (allowed for use).
> Whenever one wants to use a boost's module which is not on the
> whitelist nor the blacklist, it needs to be discussed.
> I trust your judgement on this - if you say not to use optional here,
> I will change it, but if you don't mind, we could use a similar
> whitelist for boost modules in kmm with optional being the first one
> on it.
> --
> cheers,
> Łukasz
> 2012/12/8 Alvaro Soliverez <asoliverez at kde.org>:
> > BTW, when the Transaction objects are created, they are initialized, so I
> > really don't see why boost::optional should be used here.
> >
> >
> >
> > On Sat, Dec 8, 2012 at 2:08 PM, Alvaro Soliverez <asoliverez at kde.org>
> wrote:
> >>
> >> I disagree. It's not about adding a non-Qt dependency, which KMyMoney
> >> already has a few. It's about adding a new dependency without a sound
> >> rationale, just for a convenience class that one or another developer
> has
> >> grown used to.
> >>
> >> I still don't see boost bringing in enough of an improvement to add a
> new
> >> dependency here.
> >>
> >> Besides this, my experience with boost has been horrible in the past.
> >> Removing or adding features for minor versions, API changing, no ABI
> >> compatibility and other stuff. It's not the kind of dependency I'd like
> to
> >> maintain.
> >>
> >> Regards,
> >> Alvaro
> >>
> >>
> >> On Sat, Dec 8, 2012 at 1:58 PM, Łukasz Maszczyński
> >> <lukasz at maszczynski.net> wrote:
> >>>
> >>> needed for boost::optional though, and in my opinion we shouldn't get
> rid
> >>> of boost just because it's n
> >>
> >>
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20121209/4485edae/attachment.html>

More information about the KMyMoney-devel mailing list