I see...just for chaining purposes. In some places I notice we chain this
and in others we don't.

Thanks for the clarification!


On Tue, Jan 28, 2014 at 3:13 PM, Kelven Yang <kelven.y...@citrix.com> wrote:

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


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

Reply via email to