camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <james.strac...@gmail.com>
Subject Re: minor refactoring - FooHelper -> Foos
Date Wed, 18 Feb 2009 14:48:31 GMT
We could always wait until 2.0 is almost ready to rock and roll to
minimise backport pain?

2009/2/18 Willem Jiang <willem.jiang@gmail.com>:
> +1
> Let's get it out in 2.0.
>
> Willem
>
> James Strachan wrote:
>> 2009/2/18 Claus Ibsen <claus.ibsen@gmail.com>:
>>> On Wed, Feb 18, 2009 at 1:49 PM, James Strachan
>>> <james.strachan@gmail.com> wrote:
>>>> One naming convention I really like from the Google Collections
>>>> library is using the plural name of a type/interface/base class as the
>>>> helper class for static helper methods.
>>>>
>>>> So we could rename things like ExchangeHelper to Exchanges,
>>>> CamelContextHelper to CamelContexts. Much neater IMHO.
>>>>
>>>> These helper classes are all internal mostly for Camel implementation
>>>> details; so wondering if it'd make sense to refactor them for 2.0?
>>>> Thoughts?
>>> +1
>>>
>>> Like java.util.Collections or java.util.Arrays :)
>>>
>>> What about those util classes?
>>> ResolverUtil (I dislike this name, as its not a light weight util class)
>>>
>>> And if we had a StringUtil that many framework have, should it be Strings
>>> And ObjectHelper should be Objects?
>>>
>>> A bit close to Object/String maybe hard to spot.
>>
>> Yeah! Whenever working with Objects in Google collections its actually
>> quite easy to remember after a while. Seems more natural - once you're
>> over the hump - than using Foo[Helper|Utils|Util|WhateverElse] etc I
>> often can't remember if its Helper or Util or Utils :)
>>
>
>



-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://fusesource.com/

Mime
View raw message