My 0.2 cents - I think, idea to provide getMap() method is great ! Yes, to solve the performance problem, I think, then We will have to keep track when underlying map has Changed. Then, create unmodifiable map only if it changed Since the last time...
Actually, this is a common java idiom, I think. Whenever We need to expose a collection from a class, we should return unmodifiable variant of it so that encapsulation doesn't break, but then, we have performance issue, as David said... Thanks. -----Original Message----- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 12:46 PM To: Struts Developers List Subject: Re: DynaActionForm.getMap() change --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: > > > On Wed, 16 Jul 2003, Rob Leland wrote: > > > Date: Wed, 16 Jul 2003 14:58:45 -0400 > > From: Rob Leland <[EMAIL PROTECTED]> > > To: Struts Developers List <[EMAIL PROTECTED]> > > Subject: Re: DynaActionForm.getMap() change > > > > David Graham wrote: > > > > >DynaActionForm.getMap() returns the Map that the properties are > stored in > > >without copying it to a new Map instance or wrapping it in an > unmodifiable > > >Map. IMO, we should treat that method with much more care and > > >return > an > > >unmodifiable view of the Map considering it's mainly to be used in > JSTL > > >tags. > > > > > Does this solve a problem that you or others have encountered in > practice ? > > > > I can see where a use who retrieves the Map and then modifies it could > accidentally (or on purpose) violate the type safety checks that the > normal get() and set() calls provide for you. > > > -Rob > > > > > > > >Is anyone opposed to this idea? > > My only concern would be the performance impact of this, especially if > it happens more than once in the same page (say, because you used the > same dynabean in more than one EL expression). That's why I suggested the unmodifiable wrapper technique instead of copying to a new Map. But, now that I think about it, a new wrapper class would be created each time you referenced the map which is a potential performance issue. > > An alternative approach would be to do what someone else suggested and > make DynaActionForm implement Map directly -- but make it effectively > immutable by throwing UnsupportedOperationException for Map method > calls like put() and remove(). I don't *think* there are any method > signature overlaps that would cause us any grief. I'm not convinced yet that cramming a DynaActionForm into the Map interface is appropriate. It seems like a hack. Just because it uses a Map for its implementation doesn't mean that the bean itself should be a Map. David > Craig > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
