Maybe time to add a Base64(int mode) constructor! Yay, room for 32 true/false bitwise fields!
Sorry I can't respond inline to the email like a normal person. Bad habit. yours, Julius On Tue, Mar 6, 2012 at 11:40 AM, sebb <seb...@gmail.com> wrote: > On 6 March 2012 19:33, Gary Gregory <garydgreg...@gmail.com> wrote: >> What about passing in a "boolean strict" to the constructor of the codecs? > > What does strict mean? See my comment: > > https://issues.apache.org/jira/browse/CODEC-95#comment-12986951 > > If we do add another parameter (which is not popular with others), at > least let's make sure it's the last one we need to add. > >> Gary >> >> On Tue, Mar 6, 2012 at 2:07 PM, Julius Davies <juliusdav...@gmail.com>wrote: >> >>> Hi, >>> >>> >>> CODEC-95 talked about these issues, too (in this case with Base64). >>> >>> https://issues.apache.org/jira/browse/CODEC-95 >>> >>> >>> Personally, I would prefer to see some new "strict" classes defined, >>> and to preserve the garbage-in/garbage-out behaviour on the current >>> existing classes. >>> >>> >>> Here are the new classes I would like to see: >>> >>> >>> Base32Strict >>> Base32StrictInputStream >>> Base32StrictOutputStream >>> Base64Strict >>> Base64StrictInputStream >>> Base64StrictOutputStream >>> >>> >>> At the same time it does make the API a bit more intimidating and >>> harder to learn, but I think striving for drop-in >>> reverse-compatibility of the existing classes is desirable. >>> >>> >>> yours, >>> >>> Julius >>> >>> >>> >>> >>> On Tue, Mar 6, 2012 at 6:11 AM, Gary Gregory <garydgreg...@gmail.com> >>> wrote: >>> > Hello All, >>> > >>> > We have a patch for >>> > [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>] >>> > but it is a change in behavior. In order to avoid a potential nasty >>> > surprise for call sites, we need to decide when something like this can >>> be >>> > done. >>> > >>> > In 1.6 and before, we had garbage-in-garbage-out behavior. With the >>> patch, >>> > you get an exception. >>> > >>> > 1) Is the proposed patch acceptable in the sense that we do not whant >>> GIGO? >>> > Should there instead be a validate method for example? >>> > >>> > 2) What kind of version is this change in behavior acceptable? >>> Maintenance >>> > (1.6.1), Minor (1.7) or Major (2.0)? >>> > >>> > Thank you, >>> > Gary >>> > >>> > [CODEC-134] Base32 would decode some invalid Base32 encoded string into >>> > arbitrary value >>> > >>> > -- >>> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 >>> > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK >>> > Blog: http://garygregory.wordpress.com >>> > Home: http://garygregory.com/ >>> > Tweet! http://twitter.com/GaryGregory >>> >>> >>> >>> -- >>> yours, >>> >>> Julius Davies >>> 604-222-3310 (Home) >>> >>> $ sudo apt-get install cowsay >>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n >>> http://juliusdavies.ca/cowsay/ >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 >> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- yours, Julius Davies 604-222-3310 (Home) $ sudo apt-get install cowsay $ echo "Moo." | cowsay | cowsay -n | cowsay -n http://juliusdavies.ca/cowsay/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
