Try this in java:
(4 == 4)
(new Integer(4) == new Integer(4))
well the first one is true, the second one is false. Why do I need 2 instances of the number (integer) 4 in java I don't know. I couldn't find any example (excuse). After all 4 is immutable, I cannot change it's state, I cannot make a 5 out of it.
I could say that in Smalltalk, or ruby, where everything is an object, yada, yada.... But Sun owns Java,
they own the Integer class, so when I call the constructor I should always get the same instance.
and we have the same symptoms (changed behaviour) with booleans:
(false == false)
(new Boolean(false) == new Boolean(false))
WTF !? I can have a million false objects in java. And for What? To be garbage collected, from autoboxing/unboxing? How hard is it to create a pool inside the Boolean class and to return always the FALSE object for Boolean(false) ?
Finally, there is another guy who feels my pain: "Java's new Considered Harmful . The problem stems from memory allocation and polymorphsim". Well actually he feels more pain, but that's his problem :D
Friday, June 23, 2006
Java 4s
Thursday, June 08, 2006
Java Generics Aren't
Via Steve Dekorte, from Bruce Eckel:
So [java] generics are really "autocasting."
Tuesday, June 06, 2006
NUllObject and Visitor
I have a problem with nulls: they are not objects. I cannot handle a null like any other object: I have to stop, check if it is null or not, and only after that, go on.
The problem is partially solved by throwing (checked) exception: now I have to handle an exception, instead of a null, which might have been propagated, unseen, unheard, through the stack, god-knows-where.
To the rescue comes NullObject: special object, implements the interface, does nothing.
But how do we close the implementation, but still we leave room from improvements: the Visitor: "Visitor lets you define a new operation without changing the classes of the elements on which it operates." (Actually the NullObject should be provided, in my case, by an O/R mapping layer, but I want to extend this object, for my needs). In this case, every "normal" object should do the double dispatching:
accept(Visitor v) { v.visit(this); }
only the NullObject should do nothing:
NullObject.accept(Visitor v) { }
And in C# where we have delegates, the Visitor could be a function/delegate.
-- apparently I am not the first one which thought of NullObject and Visitor.