On Jul 17, 2010, at 8:07 AM, James Carman wrote:
I've toyed (pardon the pun) with the idea of being more builderish
with
proxy, but not necessarily with the main API.
+1. I had a deeper look at how ProxyToys does its ToyFactories and I
like the fact that [proxy] has a lower-level API; then we provide
builders on top. It's not immediately obvious how to use e.g.
ProxyToys' DelegatingInvoker "directly" since there appears to be
somewhat of a circular dependency there on a ProxyFactory. I suppose
you must construct the invoker with a reference to the ProxyFactory,
then pass the invoker back to that ProxyFactory? I guess that's why
the fluent builders. Again, my stub programming piece is going to be
fluentish, but I'm not sure yet exactly what form it will take in
[proxy]. This relates to ProxyFactory's multi-pronged API. I
suppose I can provide implementations for each of delegation/
interception/invocation alike as the default response to a given
call, when not explicitly specified, might be any of these.
-Matt
I have ideas for introducing
some of the proxying "patterns" (dare I say, they might ask me to
write a
book) from HiveMind, such as pipeline and whatever the other one
was that
picked the "target" of the invocation based on the type of one of the
parameters.
On Jul 17, 2010 6:34 AM, "Jörg Schaible" <[email protected]>
wrote:
Matt Benson wrote:
On Jul 16, 2010, at 5:40 PM, Jörg Schaible wrote:
James Carman wrote:
On Fri, Jul 16, 2010 at 5:09 PM, Matt Benson
<[email protected]>
wrote:
But you can agree that making the first class a separate argument
preserves the usability of varargs while accomplishing the typed
result
in a single method?
Most definitely! I like that idea. I would think that would be the
best way to kill two birds with one stone.
This move worked out for proxytoys quite well ... ;-)
Actually it looks as though proxytoys' ProxyFactory interface
uses the
trick I just wrote about a minute ago.
And why did I never hear of proxytoys before?
Well, Apache is much more prominent than Codehaus, although in
terms of
project age, ProxyToys is older. However, both projects were
created out
of
extracted code from other projects; commons-proxy from Hivemind
(IIRC) and
ProxyToys from various Thoughtworks OS projects, most prominent
PicoContainer.
As James explained, the approach of both libraries is different,
common-
proxy allows a better optimization, while ProxyToys come with a
lot of
prebuild stuff called "toys".
All I wanted to point out that we refactored the API when updating
the
project to Java 5. Originally we used static methods as factories
for the
various toys, but now we switched to builder patterns using a lot of
generics and varargs and that turned out quite well. c-p might
benefit
from
this experience.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
