Joseph D. Darcy wrote:
Neal Gafter wrote:
You can hardly add any methods to Object, event static methods,
without breaking compatibility, because they get added to every the
overload set if the name is used for methods in existing code.
Indeed, which is why these methods were added in a new class to prevent
unwanted changes to the meaning of source code.
Ah yes I hadn't considered that. A static method in Object would be found
ahead of an imported method.
Pity - it would have been somewhat more consistent. Though I guess now only
String is "inconsistent" with regard to the 's' class convention (not that
I'd advocate changing that.)
Thanks,
David
-Joe
On Mon, Oct 26, 2009 at 9:29 AM, David Holmes <david.hol...@sun.com
<mailto:david.hol...@sun.com>> wrote:
Joseph D. Darcy wrote:
Stephen Colebourne wrote:
Joe, would you be prepared to sponsor a Strings class, and
see join on
there instead of String?
No.
+1.
It was necessary to introduce Arrays and Collections for utility
methods because there was no place else to locate the static
methods. But for String these should simply be static String methods.
But that also means I'd prefer to see additional static methods in
Object, rather than the added Objects class.
Personally I think a java.util.Utilities class containing nested
static classes for Objects, Arrays, Collections, Strings, Maps
etc, might have been a better way to organize such things. But
it's probably too late now as the duplication would be very ugly.
David
