Re: Generics and WO
Re: Generics and WO
- Subject: Re: Generics and WO
- From: Ian Joyner <email@hidden>
- Date: Wed, 23 Aug 2006 10:50:42 +1000
On 22/08/2006, at 6:53 PM, Tonny Staunsbrink wrote:
On Aug 22, 2006, at 8:14 AM, Ian Joyner wrote:
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?
This thread is moving a bit away from generics, but i couldn't help
comment on this (we recently discussed this on a current project)...
I like the java collection framework. It allows me to have som
influence on the choice of algorithm for working with collections.
What type of list needed greatly depends on the need of the code
using the collection. Linked lists can be much much faster in some
situation (and vice versa) than Array lists, but i depends on the
operations you are performing. I don't know the inner implemations
of NSArray and NSMutableArray, so i can't quite trust them to do
"the right thing" in any given situation.
My suspicion is that you only need the NS classes as glue code to EO,
since that is what is in so many of APIs. So for my own code, I'm
probably going to use the Java collection stuff, as long as it
doesn't mean lengthy conversions back and forward to NS... Of course
in dealing with EO objects, most of them are in NS structures, so may
as well deal with them directly. I still have an open mind on this
strategy, and perhaps people have already tried it.
There was a precedent in the Eiffel Cocoa library, which I thought
was going to have to do Foundation as well, but in the end, very
little of foundation was needed, only needing NSArrays, etc as
parameters and return types, which the glue code translated back and
forth from Eiffel ARRAY to NSArray, so it's much more contained that
in WO (although I agree with Lachlan, that the NS stuff is fairly
simple and elegant, which was why I used it up to now). Was also much
easier implementing garbage collection to manage Cocoa Objective-C
objects. So that is why, I think with the new generic Collections in
Java, this seems the best way to go, although the downside is
learning two sets of classes, the NS ones and Java Collection.
Generics of course change the whole way you design libraries. Look at
STL in C++ (although that came from a library in Ada, and C++'s
templates leave a lot to be desired, both in style and
implementation). As you say, it would probably a great thing to have
in WO and catch many of the errors at compile time that now don't get
caught until the program crashes. The way generics have been done
means that WO should be able to change without affecting existing
code (alright nothing's that easy!). Although, Java has left open the
possibility of some type holes (but I suppose that's the downside of
sticking something in in retrospect, but on the whole it's a pretty
good job).
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.
The prefix makes good sense in langauges with no name spaces. In
languages like Java and C# i never seen collisions become a
problem, occasionally you might have to write the fully qualified
name - I can live with that.
(And please let us have generics in WO soon - it's a nice feature -
when trying to benefit from a type srong language :-) )
Regards
Tonny
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:
40phonofile.dk
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40sportstec.com
This email sent to email@hidden
_______________________________________________
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