No problems with adding a toString, returning "Null" or somesuch.
equals and hashcode deliberately are not defined, as the class should have reference
equality only with itself, not null. There are good reasons for this. You may need a
Map where both the key null and ObjectUtils.Null have meaning. Changing equals here
would cause confusion.
Stephen
> from: Henri Yandell <[EMAIL PROTECTED]>
> As toString is meant to be a convenience method, the default
> Object.toString seems to be more useful. Is there any positive reason to
> actually return null for toString?
>
> Having Null being equal to null seems clever, but could cause issues I
> think. It's not symmetric as null.equals(..) falls over. So really
> equals(null) should throw an NPE as null.equals does.
>
> On hashCode... is there any benefit?
>
> I think 2 of the ideas make semantic sense, but I'm not sure they'd
> actually help anyone.
>
> The equals() could help people, but doesn't make semantic sense :)
>
> Hen
>
> On Wed, 3 Sep 2003, Jason Dillon wrote:
>
> > Should ObjectUtils.Null provide toString(), hashCode() & equals() as
> > such:
> >
> > public String toString() {
> > return null;
> > }
> >
> > public int hashCode() {
> > return 0;
> > }
> >
> > public boolean equals(final Object obj) {
> > if (obj == this) return true;
> > return (obj == null || obj.getClass() == getClass());
> > }
> >
> > ?
> >
> > --jason
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
