commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [proxy] Changing the API to an interface (AGAIN)...
Date Sat, 17 Jul 2010 16:20:34 GMT

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" <joerg.schaible@gmx.de>  
> 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  
>>>>> <gudnabrsam@gmail.com>
>>>>> 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: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message