This is to support fluent coding style to chain all the callback setup
calls in one line. Using caller.getTarget().callbackMethod() alone may
cause people to think the statement as a logic requirement and actually it
is not but hackings.
It is like to setup a function pointer in C or delegate in C#, but it is
kind of alien in Java world since Java does not have language level
support for this yet.
Kelven
On 1/28/14, 11:06 AM, "Mike Tutkowski" <mike.tutkow...@solidfire.com>
wrote:
>Thanks Kelven
>
>Yeah, that code is pretty crazy. :)
>
>I followed that the getTarget() method actually dynamically extends a
>class
>and allows us to inject logic in the new class that enables us to save
>createVolumeFromBaseImageCallBack as the method we want to invoke when our
>async operation has completed.
>
>It does provide the benefit that you don't have to pass in a string that
>represents the method name.
>
>What I was actually wondering about, though, is why we surround
>caller.getTarget().createVolumeFromBaseImageCallBack(null, null); with
>caller.setCallback();?
>
>It seems that setCallback() ignores the input parameter and just returns
>"this";
>
>Wouldn't caller.getTarget().createVolumeFromBaseImageCallBack(null, null);
>by itself work exactly the same way?
>
>
>On Tue, Jan 28, 2014 at 11:57 AM, Kelven Yang
><kelven.y...@citrix.com>wrote:
>
>> Mike,
>>
>> This is a very dirty hack that I personally hate it. This is the hack to
>> utilize Eclipse¹s (or other smart IDE) to do auto-completion for you to
>> find the right callback method.
>>
>> if you write
>>
>> caller.getTarget().createVolumeFromBaseImageCallBack(null, null);
>>
>> Java will interprete it as a standalone method call,
>>
>>
>> If you write as below, it tries to tell that this is to setup a
>>callback,
>> to return this in caller.setCallback is to let you continue to use
>>fluent
>> style to callback setups
>>
>> caller.setCallback(
>> caller.getTarget().createVolumeFromBaseImageCallBack(null, null) );,
>>
>> Behind scene, it uses CGLIB for dispatcher to figure out which method is
>> the callback without requiring developer to give it as literal string
>>
>>
>> AsyncMethod pattern is used commonly in parallel algorithms to
>>dynamically
>> branch out sub-calculations, I think it does not fit well in CloudStack,
>> and also due to the lack of language feature in Java, this hacking
>> technique makes the code really hard to read
>>
>> Kelven
>>
>> On 1/27/14, 6:55 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com>
>> wrote:
>>
>> >Hi,
>> >
>> >I've been looking at our callback pattern.
>> >
>> >Can someone explain why we always seem to do this?:
>> >
>>
>>>caller.setCallback(caller.getTarget().createVolumeFromBaseImageCallBack(
>>>nu
>> >ll,
>> >null));
>> >
>> >When setCallback is implemented like this:
>> >
>> >public AsyncCallbackDispatcher<T, R> setCallback(Object useless) {
>> >
>> > return this;
>> >
>> > }
>> >
>> >Why not just this?:
>> >
>> >caller.getTarget().createVolumeFromBaseImageCallBack(null, null);
>> >
>> >Thanks!
>> >
>> >--
>> >*Mike Tutkowski*
>> >*Senior CloudStack Developer, SolidFire Inc.*
>> >e: mike.tutkow...@solidfire.com
>> >o: 303.746.7302
>> >Advancing the way the world uses the
>> >cloud<http://solidfire.com/solution/overview/?video=play>
>> >* *
>>
>>
>
>
>--
>*Mike Tutkowski*
>*Senior CloudStack Developer, SolidFire Inc.*
>e: mike.tutkow...@solidfire.com
>o: 303.746.7302
>Advancing the way the world uses the
>cloud<http://solidfire.com/solution/overview/?video=play>
>*(tm)*
