camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: minor refactoring - FooHelper -> Foos
Date Wed, 18 Feb 2009 14:28:02 GMT
+1

I think the merges back to the camel-1.x are a nuisance we can live  
with and will almost disappear after the fist hump.

Hadrian

On Feb 18, 2009, at 8:37 AM, 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