My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 8: why Invoker?
1 person starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  codeto...@gmail.com
Closed:  Nov 2011


 
Project Member Reported by codeto...@gmail.com, Nov 19, 2011
I'm not sure I understand the value of Invoker.

It seems that Invoker: 

(a) translates from apply() to invoke()
(b) translates from Throwable to FuncitoEx

I wonder if Invokable should have an apply() method in the interface and/or expect implementations to catch Throwable.

Admittedly, Invokable.apply() seems a bit odd, esp. if it becomes the primary method. So, that leads me to wonder if it should be named Applicable.

Alternatively, if we ignore (a) above but strive for (b), perhaps the outer objects such as MethodFunction should hold an Invokable and call invoke().
Nov 20, 2011
Project Member #1 kandpwel...@gmail.com
I think you are right.  I think the only reason I had introduced this was because I didn't want to repeat the error handling code several places, but that is probably not worth it.  It added another unneeded layer of abstraction, which actually slowed down my performance as well.  I will look at alternatives.
Status: Accepted
Nov 22, 2011
Project Member #2 kandpwel...@gmail.com
(No comment was entered for this change.)
Status: Started
Nov 22, 2011
Project Member #3 kandpwel...@gmail.com
Fixed.  Feel free to review
Status: Fixed
Nov 22, 2011
Project Member #4 kandpwel...@gmail.com
(No comment was entered for this change.)
Labels: Priority-Medium Maintainability

Powered by Google Project Hosting