On 25 Oct 2010, at 12:41, Manik Surtani wrote:
On 11 Oct 2010, at 13:44, Mircea Markus wrote:
PS: There is no JIRA for this. If we like this approach and it works, I suggest we create a JIRA and implement it for 4.2. The impl should be simple once we resolve the outstanding bits.
there is one actually:
https://jira.jboss.org/browse/ISPN-256I'll attache the patches to it.
Just to conclude, I've POC both approaches GenericCommand and ExtendingCommand, here are my thoughts on it:
- extending visitor
PROS: ExtendingCommand is a better OO API, more strongly typed
CONS: it is harder for the user to understand; integrating custom serialization might be difficult(impossible at the time), also it will have to manage command uniques.
Why is this hard for developers to understand? Remember, these aren't *application* developers, but people *extending* Infinispan. They already ought to have an in-depth knowledge of Infinispan.
It's harder because they need to know more ISPN internals.
What do you mean by "command uniques"?
managing unique command IDs.
- GenericCommand
CONS:
- less OO API
- would require a "convention" for not "overusing" it. Overuse would be in client code though, not in ours
Client code may well be our code. E.g., more modules that we ship. -1 to a weakly typed API like this. Conventions cannot be enforced, and IMO if something can be abused, then it will be abused. :)
Just give a hammer to a kid :)