+1 On Wed, Feb 18, 2009 at 3:33 PM, Jon Anstey <jans...@gmail.com> wrote: > +1 > > On Wed, Feb 18, 2009 at 10:58 AM, Hadrian Zbarcea <hzbar...@gmail.com>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 <claus.ib...@gmail.com>: >>> >>>> On Wed, Feb 18, 2009 at 1:49 PM, James Strachan >>>> <james.strac...@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/ >>> >> >> > > > -- > Cheers, > Jon > > http://janstey.blogspot.com/ >
-- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
