Not simplifing (not complicating also), but making clear that an specific parameter is optional, it can prevent some runtime NPE by exposing in a very clear way at development time that some parameter may be null.
On Wed, Jan 5, 2011 at 3:53 PM, Martin Makundi < martin.maku...@koodaripalvelut.com> wrote: > How would it simplify actual code? > > ** > Martin > > 2011/1/5 Igor Vaynberg <igor.vaynb...@gmail.com>: > > ive recently ran into a few cases where while implementing > > ajaxfallbacklink i forgot to test the passed in request target for > > null, causing NPEs when the app was accessed from browsers where ajax > > failed for whatever reason. > > > > with all this talk of scala recently i figured why not try and > > translate one of the feature i really like in scala Option/Null/Some > > to our code base. > > > > i came up with a simple value class: > > https://gist.github.com/c38456ee75fed541c932 > > > > and changed the ajaxfallbacklink to use it > > https://gist.github.com/2f648c7feacacf18fc40 > > > > the cascade from this change was pretty impressive, a lot of places in > > our code support passing a possibly null request target but make no > > mention of it: > > https://gist.github.com/d9933e24c21f061c6ac2 > > > > so advantages: > > makes possible null value handling explicit > > no more checking the javadoc to see if the method supports null as a > > parameter value or ever returns a null > > an api break before 1.5 rc1 > > i think overall makes lives of wicket users easier > > > > disadvantages: > > a bit wordier code > > an api break just about when we are ready to release 1.5 m4/rc1 > > whatever we call it > > > > yay or nay? obviously if we say yay there are a lot more places in our > > code that can benefit from this > > > > -igor > > > -- Pedro Henrique Oliveira dos Santos
