Hi Etienne/All,
I feel as though this conversation has strayed away from what I wanted
to discuss. That was design patterns for dealing with null. I propose
there are 3 alternative solutions:
1) if (sm != null){sm.XXX();}
2) try {sm.XXX();}catch (NullPointerException e){}
3) initialise sm to a default_sm object
OO design patterns can vary. Null in Java isn't typed (unlike
languages such as UFO -
http://www.cs.man.ac.uk/arch/projects/ufo.html). I imagine that
several design patterns exist, based on language and personal
judgement. I wonder if the mailing list can suggest alternative
mechanisms for handling null.
Etienne, you have certainly convinced me from a low-level performance
perspective the 2nd of the 3 alternatives is bad. Does this mean it's
without merits though?
As for the 1st and 3rd choices, I view them as:
method 1) where sm = null :
cost = 1 compare & 1 branch
method 3) where sm = null/default_sm :
cost = 1 call & 1 return
method 1) where sm = some_sm :
cost = 1 compare & 1 branch(not taken) & 1 call/return
method 3) where sm = some_sm :
cost = 1 call/return
So where the object is usually null the 1st choice will probably offer
the best performance. Where the object is not null the 3rd choice
offers the better performance. The 3rd choice is probably larger in
binary size. So how and what do we choose?
Looking forward to feedback. Cheers,
Ian Rogers
