commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 18942] - [beanutils] Add "t/f" to BooleanConverter
Date Fri, 04 Mar 2005 14:48:19 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=18942>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=18942





------- Additional Comments From jakarta@rizzoweb.com  2005-03-04 15:48 -------
(In reply to comment #12)
> (In reply to comment #7)
> > [Eric response]
> > I disagree that using this configurable converter is not significantly easier
> > than writing your own. BeanUtils is a framework and as such should be as
> > configurable as is reasonably possible. Writing a new implementation just to
> > handle "T"/"F" is overkill, IMO.
> 
> Here's a complete implementation for a "french" boolean converter:
> 
> Converter bc = new Converter() {
>   public Object convert(Class type, Object value) {
>     String s = value.toString();
>     if (s.equalsIgnoreCase("o") || s.equalsIgnoreCase("oui"))
>       return Boolean.TRUE;
>     else if (s.equalsIgnoreCase("n") || s.equalsIgnoreCase("non"))
>       return Boolean.FALSE;
>     else
>       throw new ConversionException(s);
>   }
> }
> 
> ConvertUtils.register(bc, Boolean.class);
> ConvertUtils.register(bc, Boolean.TYPE);
> 
> This really isn't a whole lot more complicated for the user of BeanUtils than
> configuring a configurable BooleanConverter class. Note that I generally favour
> something like your original patch (a configurable BooleanConverter); I'm just
> pointing out that the current alternative isn't too bad.

It's 12-15 lines of code compared to 3 or 4; it's annonymous class creation
compared to existing class configuration; it does not implement the useful
defaultValue behavior and it will barf on null values. I'd say it is VERY
different and an order of magnitude more "complicated" (whatever that means).
Plus it has to be repeated for every set of true/false values an app might need
to support - it is no better than what we have already, which obviously needs
work as evidenced by this feature request.


> > Also, the current ConvertUtils by default registers two separate 
> > (but identical) converters for Boolean and boolean, which I think
> > is a mistake. I would amend my patch to use the same converter 
> > for both types. It doesn't matter if the user chooses form A or
> > form B that you describe above - they amount to the same thing.
> 
> Not quite. If BooleanArrayConverter is modified so it has a reference to the
> default BooleanConverter, then form A will also change the
> BooleanArrayConverter's behavior while form B will not.

But BooleanArrayConverter does not currently have a reference to
BooleanConverter, so it does not "break." I already agreed that
BooleanArrayConverter should be rewritten, at which time this could be resolved.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

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


Mime
View raw message