• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Generics and WO
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
References: 
 >Generics and WO (From: Ian Joyner <email@hidden>)
 >Re: Generics and WO (From: Ian Joyner <email@hidden>)
 >Re: Generics and WO (From: Lachlan Deck <email@hidden>)
 >Re: Generics and WO (From: Ian Joyner <email@hidden>)
 >Re: Generics and WO (From: Tonny Staunsbrink <email@hidden>)

  • Prev by Date: Re: Reusable translated button
  • Next by Date: Re: Document style webservice
  • Previous by thread: Re: Generics and WO
  • Next by thread: Dynamic treeview style navigation model.. anyone?
  • Index(es):
    • Date
    • Thread