I am one of those that use NoopAjaxRequestTarget.
I like the approach. It is clear that the parameter may be null and you
cannot forget to make the check.
What is the reason to have both isNull/isNotNull and isSet/isNotSet?
I think just isSet() is enough. It is quite easy to do "if (!isSet())
{return;}
On Wed, Jan 5, 2011 at 7:49 PM, Igor Vaynberg <igor.vaynb...@gmail.com>wrote:
> we have adopted a required-by-default style, which is correct imho.
> only a few places in our code are allowed to return null and Optional
> is a simple way to document them directly in our code.
>
> -igor
>
> On Wed, Jan 5, 2011 at 10:36 AM, Martijn Dashorst
> <martijn.dasho...@gmail.com> wrote:
> > Conversely you could create a Required<T> class that fails when a null
> > is used, properly documenting that a parameter is required.
> >
> > Martijn
> >
> > On Wed, Jan 5, 2011 at 6:44 PM, Igor Vaynberg <igor.vaynb...@gmail.com>
> wrote:
> >> 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
> >>
> >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> >
>
