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