minor refactoring - FooHelper -> Foos
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? -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
Re: minor refactoring - FooHelper -> Foos
On Wed, Feb 18, 2009 at 1:49 PM, James Strachan 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. > > -- > James > --- > http://macstrac.blogspot.com/ > > Open Source Integration > http://fusesource.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: minor refactoring - FooHelper -> Foos
However we have to be a bit careful when svnmerge from trunk to 1.x if we use a helper etc. as they have different name on trunk On Wed, Feb 18, 2009 at 1:59 PM, Claus Ibsen wrote: > On Wed, Feb 18, 2009 at 1:49 PM, James Strachan > 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. > > >> >> -- >> James >> --- >> http://macstrac.blogspot.com/ >> >> Open Source Integration >> http://fusesource.com/ >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: minor refactoring - FooHelper -> Foos
2009/2/18 Claus Ibsen : > On Wed, Feb 18, 2009 at 1:49 PM, James Strachan > 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/
Re: minor refactoring - FooHelper -> Foos
+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 : On Wed, Feb 18, 2009 at 1:49 PM, James Strachan 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/
Re: minor refactoring - FooHelper -> Foos
+1 On Wed, Feb 18, 2009 at 10:58 AM, Hadrian Zbarcea wrote: > +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 : >> >>> On Wed, Feb 18, 2009 at 1:49 PM, James Strachan >>> 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/ >> > > -- Cheers, Jon http://janstey.blogspot.com/
Re: minor refactoring - FooHelper -> Foos
+1 On Wed, Feb 18, 2009 at 3:33 PM, Jon Anstey wrote: > +1 > > On Wed, Feb 18, 2009 at 10:58 AM, Hadrian Zbarcea wrote: > >> +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 : >>> On Wed, Feb 18, 2009 at 1:49 PM, James Strachan 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/ >>> >> >> > > > -- > Cheers, > Jon > > http://janstey.blogspot.com/ > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: minor refactoring - FooHelper -> Foos
+1 Let's get it out in 2.0. Willem James Strachan wrote: > 2009/2/18 Claus Ibsen : >> On Wed, Feb 18, 2009 at 1:49 PM, James Strachan >> 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 :) >
Re: minor refactoring - FooHelper -> Foos
We could always wait until 2.0 is almost ready to rock and roll to minimise backport pain? 2009/2/18 Willem Jiang : > +1 > Let's get it out in 2.0. > > Willem > > James Strachan wrote: >> 2009/2/18 Claus Ibsen : >>> On Wed, Feb 18, 2009 at 1:49 PM, James Strachan >>> 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/
Re: minor refactoring - FooHelper -> Foos
+1 On Wed, Feb 18, 2009 at 9:48 AM, James Strachan wrote: > We could always wait until 2.0 is almost ready to rock and roll to > minimise backport pain? > > 2009/2/18 Willem Jiang : >> +1 >> Let's get it out in 2.0. >> >> Willem >> >> James Strachan wrote: >>> 2009/2/18 Claus Ibsen : On Wed, Feb 18, 2009 at 1:49 PM, James Strachan 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/ >
