<div dir="ltr"><div>Hi all<br></div><div><br></div><div>Well, nobody spoke, so I consider that everybody agrees that I can take a decision like a big girl by myself ! :) </div><div><br></div><div>I'm going to add 3 new commands, for merge, compute&computeIfPresent and computeIfAbsent. So I won't use the actual existing commands for the implementation : <span style="background-color:rgb(228,228,255);color:rgb(0,0,0);font-family:menlo;font-size:9pt">ReadWriteKeyCommand and </span><span style="background-color:rgb(228,228,255);color:rgb(0,0,0);font-family:menlo;font-size:12px">ReadWriteKeyValueCommand </span>even if I'm a DRY person and I love reusing code, I'm a KISS person too.</div><div><br></div><div>I tested the implementation using these functional commands and IMHO :</div><div class="gmail_extra">- merge and compute methods worth their own commands, they are very useful and we might want to adjust/optimize them individually <br></div><div class="gmail_extra">- there are some technical issues related to the <span style="background-color:rgb(228,228,255);color:rgb(0,0,0);font-family:menlo;font-size:9pt">TypeConverterDelegatingAdvancedCache </span>that makes me modify these existing functional commands with some hacky code that, for me, should be kept in commands like merge or compute with the correct documentation. They don't belong to a generic command.</div><div class="gmail_extra">- Functional API is experimental right now. It might be non experimental in the near future, but we might decide to move to another thing. The 3 commands are already "coded" in my branches (not everything reviewed yet but soon). If one day we decide to change/simplify or we find a nice way to get rid of commands with a more generic one, removing and simplifying should be less painful than adding commands for these methods.</div><div class="gmail_extra"><br></div><div class="gmail_extra">That's all !</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers</div><div class="gmail_extra"><br></div><div class="gmail_extra">Katia</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 12, 2017 at 12:11 PM, Katia Aresti <span dir="ltr"><<a href="mailto:karesti@redhat.com" target="_blank">karesti@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>As you might know I'm working since my arrival, among other things, on ISPN-5728 Jira [1], where the idea is to override the default ConcurrentMap methods that are missing in CacheImpl (merge, replaceAll, compute ... )</div><div><br></div><div>I've created a pull-request [2] for compute, computeIfAbsent and computeIfPresent methods, creating two new commands. By the way, I did the same thing for the merge method in a branch that I haven't pull requested yet.</div><div><br></div><div>There is an opposite view between Radim and Will concerning the implementation of these methods. To make it short :</div><div>In one side Will considers compute/merge best implementation should be as a new Command (so what is already done)</div><div>In the other side, Radim considers adding another command is not necessary as we could simple implement these methods using <span style="background-color:rgba(27,31,35,0.0470588);color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:11.9px">ReadWriteKeyCommand</span></div><div><span style="background-color:rgba(27,31,35,0.0470588);color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:11.9px"><br></span></div><div>The detailed discussion and arguments of both sides is on GitHub [2]</div><div><br></div><div>Before moving forward and making any choice by myself, I would like to hear your opinions. For the record, it doesn't bother me redoing everything if most people think like Radim because working on commands has helped me to learn and understand more about infinispan internals, so this hasn't been a waste of time for me.</div><div><br></div><div>Katia</div><div><br></div><div>[1] <a href="https://issues.jboss.org/browse/ISPN-5728" target="_blank">https://issues.jboss.org/<wbr>browse/ISPN-5728</a></div><div>[2] <a href="https://github.com/infinispan/infinispan/pull/5046" target="_blank">https://github.com/<wbr>infinispan/infinispan/pull/<wbr>5046</a></div><div><br></div></div>
</blockquote></div><br></div></div>