Re: Generics and WO
Re: Generics and WO
- Subject: Re: Generics and WO
- From: Ian Joyner <email@hidden>
- Date: Tue, 22 Aug 2006 16:14:46 +1000
On 22/08/2006, at 2:23 PM, Lachlan Deck wrote:
Hi there,
On 15/08/2006, at 2:06 PM, Ian Joyner wrote:
Reading up on this a bit more, I note that generics are
implemented, not by changing the JVM, but by 'type erasure'. The
upside of this is that programs using genericity are able to run
on older JVMs and you still get compiler checks and are able to
cast your casts to the wind.
Downside though is that cast checks will still be done at runtime,
even though a class cast error can't occur, so there is no speed
up due to stronger typing.
Interesting...
Now I have to admit to being a bit lazy and have just been using
NSArray, NSDictionary, etc in preference to Java Collections and
Arrays, but now with genericity, the Java collection hierarchy has
a lot more going for it.
I've always preferred the NS collections as being well written,
powerful (esp in combination with KVC) and uncomplicated. NS
[Mutable]Array, NS[Mutable]Set, NS[Mutable]Dictionary provide most
functionality needed from collections.
I agree, until I looked at the 1.5 stuff. It is good to have mutable
and immutable collections. Eiffel had the same hierarchy to
distinguish, but in the end decided to have a mutable/immutable
qualifier for object declarations. It simplifies the class hierarchy
a lot. It was also decided to do away with the pair of numeric
classes like INTEGER and INTEGER_REF, rather having i: INTEGER and
ir: reference INTEGER (although that was still neater than having int
and Integer, etc).
The Java Collections don't provide immutable collections by default
and seem to have too many options of doing the same thing without
much advantage. (e.g., for Lists - have ArrayList, Vector,
LinkedList etc etc).
It's true that Java is weak on immutables. In the new Collection
hierarchy, some classes are kept for backwards compatibility, like
Vector, so by avoiding them, it becomes a bit simpler. The others are
implementation variants, so I tend to:
List <String> ls = new ArrayedList <String> ();
that way if there is a performance problem or flexibility problem
later, I can choose one of the alternative implementations.
I think the java 1.5 libraries are greatly enhanced (although still
no where near as comprehensive and elegant as in EiffelBase), and
genericity has also made a huge improvement. Do you have any feeling
as to the performance of NSArray vs Java's Array implementation of
Collections? The Java people claim Collections is highly optimized. I
suspect these could actually be done in native code in the JVM or
through JNI, using the Java definitions just as bridges, but are they?
I gather Apple have put WO development on hold, or opened it up a
lot more. So does that mean that NS (a dumb naming convention)
structures
NS<somename> is a good naming convention. i.e., There are two
things in play that provide uniqueness to a class name - (1) the
name's Prefix and (2) the package (should the former fail). If
you've used 'import' statements in your java class (which most do -
and which Eclipse and the like do automatically for you) then
without the first condition you'd be more often than not using full-
package-namespaces throughout your code which would be ugly.
Well, I could have said that about naming conventions in general, but
as pointed out by Apple's own engineers last year, NS was a dumb
thing to call it because now the library is not called NextStep, it
is Cocoa, so it should have been CArray, etc, but naming conventions
make things too hard to change, so now I'll have a general comment
about dumb naming conventions, although as you point out, in the case
of Java libraries and packages they have a legitimate reason.
But thinking about the way Eiffel does it again, there are no imports
in every file, just one file listing all the used libraries. If there
are name clashes between libraries, you can solve it in the one file,
eg Use Array from Java_util as JArray and Use Array from Foundation
as NSArray. That way, you never have the complication and
inflexibility of fully qualified names throughout your code.
Ian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden