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.
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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/ts%
40phonofile.dk
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to archive@mail-archive.com
