[Mono-dev] Suggestion: Mono.Collection really useful

Jonathan Pryor jonpryor at vt.edu
Sat Sep 30 09:17:30 EDT 2006


On Sat, 2006-09-30 at 12:13 +0200, Francisco Modesto wrote:
> I did'n understand some things. Why the effort for be 100% compatible with 
> Microsoft, if they did'nt want to be compatibles with nothing???

Because Microsoft is the 8e6 lb gorilla of the industry, and if you're
not compatible with them you have a harder time "selling" your wares.
Java competes because it's backed by several other large gorillas (Sun,
IBM, etc.).

Do you see any "major" platform that *isn't* backed by a large gorilla?
Python?  Ruby?  Perl?  Yes, they have large followings, but I doubt that
their audience is as large as .NET or Java.

So compatibility with .NET is a benefit.  Even if they're only
compatible  with themselves, it provides us a way to say "You can take
the code you've already written and migrate it to Mono with minimal
effort" (which sells *much* better than Java's "If you *rewrite* all of
your code in Java you can use it everywhere (maybe)").

> Specially with assemblies. I think there is many good things in Java than C#. 
> Why re-code the wheel? C# assemblies are all but friendly and are designer by 
> #!$#@#. I know it's not your fault.

Care to elaborate?  I far prefer the concept of strongly versioned
assemblies over the mess of Java .jar files & CLASSPATH, especially the
Java class boot loader, the ordering of .jar files to specify which type
actually gets loaded (in case you have, I don't know, multiple different
XML parsers with interfaces from the org.w3c package, which was somewhat
common before Java 1.4 added XML support).

Assemblies are *far* cleaner, and make for a much nicer deployment
message.  Compare: "Place all your dependent .dll files into the same
directory as the .exe" to "Edit CLASSPATH, and/or place files into the
java boot directory, or...  and if you have multiple types with the same
full name in different .jar files, all bets are off!"

> Someone can explain why System.Collection.IList has Item[]???? A list is not 
> an array!!!! Maybe ToArray() method that returns an array?

It's operator overloading, and one of the things that makes C# a
higher-level language than Java.

IList.Item() is an indexer, allowing use such as:

	int n = myType [index];

even though it really invokes get_Item() and set_Item() methods.

Furthermore, System.Array implements System.Collections.IList.

This allows high level generic code:

	static void Count (IList items)
	{
		int c = 0;
		for (int i = 0; i < items.Count; ++i)
			// indexer use, *not* array access
			c += items [i];
		return c;
	}

Witch can be used with *any* type implementing IList, *including*
System.Array:

	Count (new int[]{1, 2, 3, 4});

	List<int> l = new List<int> ();
	l.Add (5); l.Add (6); l.Add (7);
	Count (l);

	ArrayList al = new ArrayList ();
	al.Add (8); al.Add (9); al.Add (10);
	Count (al);

I for one wish Java made things this easy, but it didn't.

This is high-level polymorphism in action.

> I miss a lot of classes, specially Collections class. List, Map, Set... 

Look at the Mono.C5 assembly, which contains many of these special
collections classes.  Though I don't see what's wrong with the
System.Collections & System.Collections.Generic types.  Sure, there's no
Set<T>, but Dictionary<K,V> suffices, just use the keys as a set.

> I think the main power of Java is that you as programmer only have to worrier 
> about your own problem, not implementing a lot of common stuff code.

The same is largely true of .NET.

> I'm not sure if I'm in the right mail-list, sorry if I'm wrong.

mono-list is probably a better mailing list.

 - Jon





More information about the Mono-devel-list mailing list