camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Tam <email.w...@gmail.com>
Subject Re: minor refactoring - FooHelper -> Foos
Date Wed, 18 Feb 2009 18:03:16 GMT
+1

On Wed, Feb 18, 2009 at 9:48 AM, James Strachan
<james.strachan@gmail.com> wrote:
> 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