I think it absolutely makes sense (for a future release of wicket).
having a NullObject instance of AjaxRequestTarget would not waste a lot
of cpu cycles at all, at least not how i use it. the only thing i do
with the object is call .addComponent() and then refering a
already-initialized variable.
how likely is it that the object is in fact null? its <5% of users who
have javascript disabled. so this would affect only a small amount of
requests.
from a jvm perspective calling methods with empty bodys very often is
not something expensive. they will get inlined by the hotspot compiler
and be effectively free. (i am not 100% sure if this also applys to
polymorphism chains.)
from a "clean-code" prespective it is often considered a code smell to
have a lot of null checks.
in your example providing a FakeDatabaseConnection that throws an
UnsrupportedOperationException("you have no database!") is better than
seeing a null pointer exception.
Sounds weird.
Why should my component burn cpu cycles to feed a fake ajax target
which does nothing at all?
I would prefer some null checks in that case.
Would you also provide a FakeDatabaseConnection in case you
application does not support databases? :-)
Am 24.10.2009 um 07:42 schrieb Vladimir Kovalyuk:
I believe all those null-checks of request target can be omited in
user code
if fallback components would provide fake implementation of
AjaxRequestTarget instead of passing null.
Does it make sense?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
