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

[Łukasz Maszczyński]

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
>>
>>
>