RE: Conversion to ToStringBuilder
I agree, the less jars the better. As far as containers shipping with commonly used jar files, these common applications aren't standing still and we test with the specific jars are applications are using, wouldn't this be confusing and possibly waste more time that it saves. Edgar > -Original Message- > From: Vic Cekvenich [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 09, 2003 2:29 PM > To: [EMAIL PROTECTED] > Subject: Re: Conversion to ToStringBuilder > > > The less jars, the better. > > I have like 2 dozen. I wish containers shipped with some > commons-* jars > and xml handling jars, like Tomcat does. > > Really, servelt 2.5 spec should state something like jars > needed by 80% > of apps (collections, beans, log4j, xmltypes suggested) > should be in the > container common lib. No, not the silly j2ee.jar which has > things that > are used by 15% of people (yes, it's a scientific #, it says > this, if I > do not need it, no one needs it). I mean even rt.jar is 18 > megs, why not > containers have some stuff, we already have class loader > issues anyway. bP is only 90K, but needs a lot of jars to wake up. > > I happen to use lang for other things so this one does not > help me and > it would detriment and active commiter. > > .V > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conversion to ToStringBuilder
Of course, Struts could (almost) get the best of both worlds by wrapping ToStringBuilder inside a Struts class and use that class instead. The small overhead of the extra call would only kick in when logging is enabled. Whenever it's decided that c-l.TSB dependency should be dropped, it's easy enough to put implementation code in (in this case). Either way, you'd still get object reuse, ease of use, and consistent implementation across the codebase. It's also easy enough that if any of the committers didn't wanna do it, someone else will. Plus, if like David said, lists need to be handled differently, it can be programmed in and reused by other classes, again for consistency. --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > Quoting David Graham <[EMAIL PROTECTED]>: > > > I think we inherit the dependency on commons lang from some other > > component. Our use of lang's features is very limited and my preference > > is to keep it that way. Regardless, toString() is easy to implement > > without ToStringBuilder. > > > > Last time I looked, ToStringBuilder was the only dependency we have on > commons-lang. I'd much rather do a little more work in our toString() methods > and dump the dependency if that's actually the case, unless there's some > compelling need for any of the other c-l methods. > > > David > > Craig > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conversion to ToStringBuilder
The less jars, the better. I have like 2 dozen. I wish containers shipped with some commons-* jars and xml handling jars, like Tomcat does. Really, servelt 2.5 spec should state something like jars needed by 80% of apps (collections, beans, log4j, xmltypes suggested) should be in the container common lib. No, not the silly j2ee.jar which has things that are used by 15% of people (yes, it's a scientific #, it says this, if I do not need it, no one needs it). I mean even rt.jar is 18 megs, why not containers have some stuff, we already have class loader issues anyway. bP is only 90K, but needs a lot of jars to wake up. I happen to use lang for other things so this one does not help me and it would detriment and active commiter. .V Craig R. McClanahan wrote: Quoting David Graham <[EMAIL PROTECTED]>: I think we inherit the dependency on commons lang from some other component. Our use of lang's features is very limited and my preference is to keep it that way. Regardless, toString() is easy to implement without ToStringBuilder. Last time I looked, ToStringBuilder was the only dependency we have on commons-lang. I'd much rather do a little more work in our toString() methods and dump the dependency if that's actually the case, unless there's some compelling need for any of the other c-l methods. David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conversion to ToStringBuilder
--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > Quoting David Graham <[EMAIL PROTECTED]>: > > > I think we inherit the dependency on commons lang from some other > > component. Our use of lang's features is very limited and my > preference > > is to keep it that way. Regardless, toString() is easy to implement > > without ToStringBuilder. > > > > Last time I looked, ToStringBuilder was the only dependency we have on > commons-lang. I'd much rather do a little more work in our toString() > methods > and dump the dependency if that's actually the case, unless there's some > compelling need for any of the other c-l methods. > Craig We're using some of lang's String methods in the test cases because we're not on Java 1.4. David __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conversion to ToStringBuilder
Quoting David Graham <[EMAIL PROTECTED]>: > I think we inherit the dependency on commons lang from some other > component. Our use of lang's features is very limited and my preference > is to keep it that way. Regardless, toString() is easy to implement > without ToStringBuilder. > Last time I looked, ToStringBuilder was the only dependency we have on commons-lang. I'd much rather do a little more work in our toString() methods and dump the dependency if that's actually the case, unless there's some compelling need for any of the other c-l methods. > David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Conversion to ToStringBuilder
I agree that the content (in terms of what fields are useful) of the toString() ouput will vary and is subject to the programmer's descretion but the format in which it is output should be fairly consistent. Maybe I'm just anal but I don't like to see a mix of toString formats in a single codebase. -- Norm Deane MIS Consultant Vanderbilt University (615) 322-7855 [EMAIL PROTECTED] > -Original Message- > From: David Graham [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 06, 2003 12:48 PM > To: Struts Developers List > Subject: RE: Conversion to ToStringBuilder > > > > --- Norm Deane <[EMAIL PROTECTED]> wrote: > > Ok. The nice thing about ToStringBuilder is that it ensures > > consistency across all your toString methods and provides > the ability > > to adopt a new toString style without changing a lot of code. > > I don't see the need for this. toString() implementations > must vary depending on their use. For example, List > implementations generally use "[item1,item2]" while other > classes just want to output some debugging information. > > David > > > > > -- > > Norm Deane > > MIS Consultant > > Vanderbilt University > > (615) 322-7855 > > [EMAIL PROTECTED] > > > > > -Original Message----- > > > From: David Graham [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, November 06, 2003 10:26 AM > > > To: Struts Developers List > > > Subject: Re: Conversion to ToStringBuilder > > > > > > > > > I think we inherit the dependency on commons lang from some > > > other component. Our use of lang's features is very limited > > > and my preference is to keep it that way. Regardless, > > > toString() is easy to implement without ToStringBuilder. > > > > > > David > > > > > > --- Norm Deane <[EMAIL PROTECTED]> wrote: > > > > I was thinking about adding a toString method to > > > ModuleConfigImpl that > > > > used ToStringBuilder but I noticed some of the other config > > > > objects > > > > have toString > > > > methods that do not use ToStringBuilder. Anyone object to > > > me writing a > > > > patch that converts the existing toString methods to use > > > ToStringBuilder > > > > and > > > > adding one to ModuleConfigImpl? > > > > > > > > --Norm > > > > > > > > -- > > > > Norm Deane > > > > MIS Consultant > > > > Vanderbilt University > > > > (615) 322-7855 > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > __ > > > Do you Yahoo!? > > > Protect your identity with Yahoo! Mail AddressGuard > > > http://antispam.yahoo.com/whatsnewfree > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > __ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > http://antispam.yahoo.com/whatsnewfree > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Conversion to ToStringBuilder
--- Norm Deane <[EMAIL PROTECTED]> wrote: > Ok. The nice thing about ToStringBuilder is that it ensures consistency > across all your toString methods and provides the ability to adopt a new > toString style without changing a lot of code. I don't see the need for this. toString() implementations must vary depending on their use. For example, List implementations generally use "[item1,item2]" while other classes just want to output some debugging information. David > > -- > Norm Deane > MIS Consultant > Vanderbilt University > (615) 322-7855 > [EMAIL PROTECTED] > > > -Original Message- > > From: David Graham [mailto:[EMAIL PROTECTED] > > Sent: Thursday, November 06, 2003 10:26 AM > > To: Struts Developers List > > Subject: Re: Conversion to ToStringBuilder > > > > > > I think we inherit the dependency on commons lang from some > > other component. Our use of lang's features is very limited > > and my preference is to keep it that way. Regardless, > > toString() is easy to implement without ToStringBuilder. > > > > David > > > > --- Norm Deane <[EMAIL PROTECTED]> wrote: > > > I was thinking about adding a toString method to > > ModuleConfigImpl that > > > used ToStringBuilder but I noticed some of the other config objects > > > have toString > > > methods that do not use ToStringBuilder. Anyone object to > > me writing a > > > patch that converts the existing toString methods to use > > ToStringBuilder > > > and > > > adding one to ModuleConfigImpl? > > > > > > --Norm > > > > > > -- > > > Norm Deane > > > MIS Consultant > > > Vanderbilt University > > > (615) 322-7855 > > > [EMAIL PROTECTED] > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > __ > > Do you Yahoo!? > > Protect your identity with Yahoo! Mail AddressGuard > > http://antispam.yahoo.com/whatsnewfree > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Conversion to ToStringBuilder
Ok. The nice thing about ToStringBuilder is that it ensures consistency across all your toString methods and provides the ability to adopt a new toString style without changing a lot of code. -- Norm Deane MIS Consultant Vanderbilt University (615) 322-7855 [EMAIL PROTECTED] > -Original Message- > From: David Graham [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 06, 2003 10:26 AM > To: Struts Developers List > Subject: Re: Conversion to ToStringBuilder > > > I think we inherit the dependency on commons lang from some > other component. Our use of lang's features is very limited > and my preference is to keep it that way. Regardless, > toString() is easy to implement without ToStringBuilder. > > David > > --- Norm Deane <[EMAIL PROTECTED]> wrote: > > I was thinking about adding a toString method to > ModuleConfigImpl that > > used ToStringBuilder but I noticed some of the other config objects > > have toString > > methods that do not use ToStringBuilder. Anyone object to > me writing a > > patch that converts the existing toString methods to use > ToStringBuilder > > and > > adding one to ModuleConfigImpl? > > > > --Norm > > > > -- > > Norm Deane > > MIS Consultant > > Vanderbilt University > > (615) 322-7855 > > [EMAIL PROTECTED] > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > __ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > http://antispam.yahoo.com/whatsnewfree > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Conversion to ToStringBuilder
I think we inherit the dependency on commons lang from some other component. Our use of lang's features is very limited and my preference is to keep it that way. Regardless, toString() is easy to implement without ToStringBuilder. David --- Norm Deane <[EMAIL PROTECTED]> wrote: > I was thinking about adding a toString method to ModuleConfigImpl that > used > ToStringBuilder but I noticed some of the other config objects have > toString > methods that do not use ToStringBuilder. Anyone object to me writing a > patch that converts the existing toString methods to use ToStringBuilder > and > adding one to ModuleConfigImpl? > > --Norm > > -- > Norm Deane > MIS Consultant > Vanderbilt University > (615) 322-7855 > [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
