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
On Wed, Jan 5, 2011 at 11:44 AM, 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
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
We use only Ajax or non-Ajax components. No fallbacks. I think in the
(near) future we don't really need fallbacks. Everything is javascript
nowdays. Only mammooths are fallback.
From that perspective it seems excess to add code to make something
nice that is not going to exist for long.
On Wed, Jan 5, 2011 at 12:13 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
We use only Ajax or non-Ajax components. No fallbacks. I think in the
(near) future we don't really need fallbacks. Everything is javascript
nowdays. Only mammooths are fallback.
From that perspective it
Conversely you could create a RequiredT 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
I think this is one for 1.6, so we can flesh out any issues that arise
from this style of programming.
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
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
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())
They are there to aid readability.
Sometimes opt.isNotSet is more readable the opt.isNull
-igor
On Jan 5, 2011 11:49 AM, Martin Grigorov mgrigo...@apache.org wrote:
I am one of those that use NoopAjaxRequestTarget.
I like the approach. It is clear that the parameter may be null and you
10 matches
Mail list logo
