struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dbros...@qis.net
Subject Re: Proposed Action base class change
Date Thu, 07 Oct 2004 19:00:58 GMT
I agree with the == comment, but even if you wanted to go hashCode, you could
use System.identityHashCode( obj );

Quoting Paul Speed <pspeed@progeeks.com>:

> I'd just like to point out that the only valid way to tell if two 
> objects are the same instance if to use ==.  Any other approach will not 
> work.
> 
> Comparing the toString() method results as you do is only really 
> comparing the hashcodes... which are not unique by a long shot (I never 
> assume people know this).  Besides, == is even faster.  What cases do 
> you find that you've had to use .toString().equals(...) where you 
> couldn't just do an == check?
> 
> -Paul
> 
> Hiran.Chaudhuri@softwareag.com wrote:
> 
> > Hi, Frank.
> > 
> > I do not agree. While in most cases it is desireable to see inside a bean
> (hence I created my 
> > 	public static String toString(Object bean)
> > method), there are times when I just have to make sure a bean is not just
> equal but the same instance.
> > The java.lang.Object.toString() methods allows me to that quite quickly as
> the memory address is printed.
> > 
> > Unless you have another way to provide that information, I'd rather stick
> with the default toString() plus some utility toString(Object) method. The
> impact for you is not too much. What you code so far is:
> > 	log.debug("mybean="+mybean);
> > and you'd have to change that to
> > 	log.debug("mybean="+BeanUtil.toString(mybean));
> > which will allow you to either see the memory address or the contents,
> whatever you prefer.
> > 
> > Hiran
> > 
> > -----------------------------------------
> > Hiran Chaudhuri
> > SAG Systemhaus GmbH
> > Elsenheimer Straße 11
> > 80867 München
> > Phone +49-89-54 74 21 34
> > Fax   +49-89-54 74 21 99
> > 
> > 
> >  
> > 
> > 
> >>-----Original Message-----
> >>From: Frank W. Zammetti [mailto:fzlists@omnytex.com] 
> >>Sent: Donnerstag, 7. Oktober 2004 13:43
> >>To: Struts Developers List
> >>Subject: Re: Proposed Action base class change
> >>
> >>Hi Niall,
> >>
> >>I certainly agree it would not be possible to satisfy 
> >>everyone, but seeing as the intrinsic toString() is all but 
> >>useless (and people do generally expect that to be the case 
> >>with many classes), why not give an implementation that is of 
> >>at least some use to some people?  Surely it would be better 
> >>than what you get now?  Obviously it's something many people 
> >>will override, and that's of course the whole point of 
> >>inheritance.  But providing even a slightly more useful 
> >>default implementation (and maybe telling people it's a basic 
> >>default implementation so as to try and keep the flood of 
> >>bugzilla requests to a
> >>minimum) seems to me like a good idea.
> >>
> >>I can't address your point about dynabeans because I haven't 
> >>used them enough to be able to intelligently comment (which 
> >>is to say I haven't used them at all! :) )... I wouodn't 
> >>imagine some basic implementation would be too tough for them as well.
> >>
> >>In any case, I will look at the toString builders you 
> >>mentioned... I've come to really like using the commons 
> >>packages and I try to whenever I can.  This would be a good 
> >>case I think, if it doesn't get added as I proposed.  I 
> >>already have an ActionHelpers class with a bunch of 
> >>similarly-themed static methods for use from Actions, so 
> >>maybe it's time to do so for forms as well.
> >>
> >>--
> >>Frank W. Zammetti
> >>Founder and Chief Software Architect
> >>Omnytex Technologies
> >>http://www.omnytex.com
> >>
> >>Niall Pemberton wrote:
> >>
> >>>Frank,
> >>>
> >>>For me it wouldn't be any use unless it also handled 
> >>
> >>DynaBeans. Even 
> >>
> >>>then I'd end up overriding it because I have some formatting utils 
> >>>which do dates, arrays and collections. Seems to me if we put it in 
> >>>then we would end up with a monster trying to satisy 
> >>
> >>everyones needs 
> >>
> >>>and forever dealing with bugzilla requests for enhacements (someone 
> >>>would want an i18n version!) - all just for debugging.
> >>>
> >>>The easiest thing is to just put all that code into a 
> >>
> >>utility method - 
> >>
> >>>that way its only a one liner in the toString() - even 
> >>
> >>better if you 
> >>
> >>>have your own "base" ActionForm that all you others derive 
> >>
> >>from, then 
> >>
> >>>its only in one place.
> >>>
> >>>Also, there are a set of "toString" builders in commons 
> >>
> >>lang which you 
> >>
> >>>might like to use - including a reflection one like yours:
> >>>
> >>>
> >>
> >>http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui
> >>
> >>>lder/package-summary.html 
> >>>
> >>
> >>http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/bui
> >>
> >>>lder/ReflectionToStringBuilder.html
> >>>
> >>>Niall
> >>>
> >>>----- Original Message -----
> >>>From: "Frank W. Zammetti" <fzlists@omnytex.com>
> >>>To: "Struts Developer" <dev@struts.apache.org>
> >>>Sent: Thursday, October 07, 2004 4:29 AM
> >>>Subject: Re: Proposed Action base class change
> >>>
> >>>
> >>>
> >>>
> >>>>Obviously I made a typo in the subject... this applies to the 
> >>>>ActionForm base class.
> >>>>
> >>>>Did anyone have any comment on this?  I've noticed a lack 
> >>
> >>of activity 
> >>
> >>>>on the list lately...
> >>>>
> >>>>
> >>>>
> >>>>>Hello all...
> >>>>>
> >>>>>I find myself all the time overloading toString() of my 
> >>
> >>ActionForms 
> >>
> >>>>>for
> >>>
> >>>debugging
> >>>
> >>>
> >>>>>purposes, so I can easily dump the current state of the object. 
I 
> >>>>>had
> >>>
> >>>been doing
> >>>
> >>>
> >>>>>this for each ActionForm class, specifically for it, but 
> >>
> >>it ocurrs to 
> >>
> >>>>>me
> >>>
> >>>that a
> >>>
> >>>
> >>>>>general-purpose reflection-based approach would be better.
> >>>>>
> >>>>>I'd like to propose adding this functionality to the 
> >>
> >>ActionForm base
> >>
> >>>class.  Here's
> >>>
> >>>
> >>>>>the code I propose adding:
> >>>>>
> >>>>>import java.lang.reflect.Field;
> >>>>>public static final AVERAGE_FIELD_SIZE = 25; public String 
> >>
> >>toString() 
> >>
> >>>>>{
> >>>>> String str = "";
> >>>>> StringBuffer sb = null;
> >>>>> try {
> >>>>>   Field[] fields = this.getClass().getDeclaredFields();
> >>>>>   sb = new StringBuffer(fields.length * AVERAGE_FIELD_SIZE);
> >>>>>   for (int i = 0; i < fields.length; i++) {
> >>>>>     if (sb.length() > 0) { sb.append(", "); }
> >>>>>     sb.append(fields[i].getName() + "=" + fields[i].get(this));
> >>>>>   }
> >>>>>   str = sb.toString().trim();
> >>>>> } catch (Exception e) {
> >>>>>   str = "Exception in ActionForm.toString() : " + e;
> >>>>> }
> >>>>> return str;
> >>>>>}
> >>>>>
> >>>>>The value of AVERAGE_FIELD_SIZE is a matter of debate, and it's of
> >>>
> >>>course impossible
> >>>
> >>>
> >>>>>to come up with a real value, so something reasonable is 
> >>
> >>the answer.  
> >>
> >>>>>25
> >>>
> >>>struck me
> >>>
> >>>
> >>>>>as a decent starting point.
> >>>>>
> >>>>>What does everyone think?  I find this functionality to be very 
> >>>>>useful
> >>>
> >>>in my work,
> >>>
> >>>
> >>>>>and I suspect others may as well.  The code doesn't add any 
> >>>>>dependencies
> >>>
> >>>outside
> >>>
> >>>
> >>>>>J2SE, and it's certainly simple enough as to not be 
> >>
> >>particularly risky.
> >>
> >>>>>Thanks all!
> >>>>>
> >>>>>Frank W. Zammetti
> >>>>>Founder and Chief Software Architect
> >>>>>Omnytex Technologies
> >>>>>http://www.omnytex.com
> >>>>>
> >>>>
> >>>>
> >>>>------------------------------------------------------------
> >>
> >>---------
> >>
> >>>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For 
> >>>>additional commands, e-mail: dev-help@struts.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>---------------------------------------------------------------------
> >>
> >>>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For 
> >>>additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For 
> >>additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message