Thanks for replies.
I was hoping it was possible to express this in a shorter way
I hadnt figured out, but it seems it is not possible to avoid
this null-pointer problem then...
Well, it *can* be minimised [or perhaps better hidden] by making use of the
NullObject design pattern [another poster - Andrew McDonagh - already
mentioned this approach].
The approach entails having methods always return an object [thereby
eliminating the need for a 'if (object == null)' test], and where you would
normally return a null, you return an 'empty' or 'default-valued' object
[i.e. all its fields are set to predetermined values] - a NullObject - one
that behaves as an object of its type should, but one that does nothing
consequential.
A Google search will doubtless turn up more information on this topic.
Of course this approach is only useful in classes you implement. If using
API methods that return null you really have no choice but to perform the
'if (object == null)' test since there is no guarantee [unless exception
handling is used] an object [and not a null] will be returned.
Personally, from a practical viewpoint,
since strings are so frequently used and clutter up syntax
and readability in common cases like this,
it seems to me like a fundamental design-flaw in Java to
define String as objects in the first place.
I'm very sold on OOP in general, but still,
wouldn't String have been better defined as a primitive
type? That would also have avoided a lot of awkward
things like s.equals(t) instead of the neater
s==t
etc.
Is there any good reason String was defined as object
in Java?
Actually, I think the question you should be asking is:
Why did Java implement primitive types ? [thus introducing
the complications associated with handling both objects
and primitives]
The reason for asking this question is that a truly 'pure' OOPL would only
support objects [Smalltalk being the classic example]. That Java, and many
other OOPL's make a distinction between primitives and objects is [I
believe] purely for performance reasons. Primitives map directly to hardware
components [i.e. CPU registers] so that many operations can be performed
directly on the hardware, thus bypassing the overhead associated with
object-handling.
Strings do not map to any hardware component, thus the performance benefit
from implementing them as primitives [even if this were easy to do] doesn't
exist. Besides, you'd still need to make method calls on the string [sounds
like a utility class might be needed], so I don't see that making it a
primitive gains anything in the usage stakes.
Finally, the awkwardness you mention [between s == t and s.equals(t)] could
perhaps be addressed via the introduction of a new operator, one that can be
mapped to a class' 'equals' method ? Thus, instead of dong this:
s.equals(t);
you might do something like this:
s <=> t
You certainly couldn't use the '==' operator because [as another poster -
Patricia Shanahan - mentions] Java variables that refer to objects are
really pointers, so that this:
s == t
is a test for pointer equality; this operator would need to remain as is to
maintain current language semantics.
I hope this helps.
Anthony Borla
