Jeroen,

You may want to plan on using the C# generics support in the upcoming Whidbey class libraries and runtime to implement your ghost interfaces in future IKVM releases. They should release a prerelease an the end of the month. See: http://research.microsoft.com/projects/clrgen/generics.pdf
You can experiment with the implementation now with the Gyro generics implementation running on rotor. See Gyro at: http://research.microsoft.com/research/downloads/

Oh no! Don't give Jeroen an excuse to require 2.0! I still want 1.0 support! ;)

Just last week I was enquiring as to whether it would be possible for IKVM to support the 1.0 framework version. Jeroen's reply was that it wouldn't be hard in theory to make the relevant parts of the code conditional, but that it would be subject to bitrot when parts of the code with obscure 1.0 workarounds are rewritten and the workarounds get forgotten.

At the very least, I hope that we stay on 1.1 until there's a VS.NET corresponding to 2.0...

Another thought on framework versions:

It's (probably) too late for 1.0, but would you consider switching to a "real" version number system rather than just "the latest snapshot" before requiring a new framework version? That way, as long as my program works with some past IKVM release, I can always recommend to users to get that version if they need 1.1 support, even after 2.0 is required by newer versions.

// Jeroen,

Here's what I was suggesting for using generics for ghost interfaces. I haven't tested this code at all but I wanted to get back to you on what I was thinking from what I read about gyro:


// Consider the following example:

using Object = System.Object;
using String = System.String;
using StringBuffer = java.lang.StringBuffer;
using Character = java.lang.Character;
using CharSequence = java.lang.CharSequence;

class Test
{
/*
public static CharSequence toUpperCase(CharSequence seq)
{
StringBuffer buf = new StringBuffer();
int len = seq.length();
for(int i = 0; i < len; i++)
{
char c = seq.charAt(i);
c = Character.toUpperCase(c);
buf.append(c);
}
return buf;
}
public static void Main ()
{
String s = "abc";
String theUpperCaseString = Test.ToUpperCase (s);
}
*/
}

// Your current ghost implementation compiles into something like the following:

class TestCompiled
{

// Currently, you compile this as something like:

private static object toUpperCase(object seq)
{
StringBuffer buf = new StringBuffer();
int len;
if(seq is String)
{
len = ((String)seq).Length;
}
else
{
len = ((CharSequence.__Interface)seq).length();
}
for(int i = 0; i < len; i++)
{
char c;
if(seq is String)
{
c = ((String)seq) [i];
}
else
{
c = ((CharSequence.__Interface)seq).charAt(i);
}
c = Character.toUpperCase(c);
buf.append(c);
}
return buf;
}
public static void Main ()
{
string s = "abc";
string theUpperCaseString = (string) toUpperCase (s);
}
}

// I have not tested this code since I haven't yet installed gyro and rotorl, but from what I read about generics, you might be able to do something like the following:

interface CharSequence<V>
{
char charAt (V theSequence, int i);
int length (V theSequence);
}

class CharSequenceHelper

{
public static char charAt<V>(CharSequence<V> s, int i) where V: CharSequence<V> (string<V> s) { return (s.charAt (i); }
public static int length<V>(CharSequence<V> s) where V: CharSequence<V> (string<V> s) { return (s.length(); }
}

class TestCompiledWithGenerics
{
public static CharSequence<V> toUpperCase(CharSequence<V> seq)
{
StringBuffer buf = new StringBuffer();
int len = CharSequenceHelper.length(seq);
for(int i = 0; i < len; i++) {
char c = CharSequenceHelper.charAt(seq, i);
c = Character.toUpperCase(c);
buf.append(c);
}
return buf;
}
public static Main ()
{
string s = "abc";
string theUpperCaseString = TestCompiledWithGenerics.ToUpperCase<string> (s);
}
}

I think I disagree that the design being in flux is a good reason to stay away from real version numbers. On the contrary, I think it's an excellent reason to *use* real version numbers.

Consider that if someone shows up on the mailing list with problems in a version of IKVM they downloaded "a while ago", they may not be able to give a specific date that they downloaded it on, but they can certainly type "ikvm -version" (which currently, unless I'm mistaken, doesn't give information that would be useful to figure out how old of a snapshot it is). You could then correlate the release date of that version against blog entries and mailing lists to figure out what the architecture was like at that point in time and give useful suggestions.

Even if the version number is "0.0.20031016" (the last part being the date) at least there's some way to say which version you mean, rather than "the latest snapshot as of last Thursday" I'd also like to be able to get prior snapshots - for example, if the last version that supported 1.0 were available anywhere in source form, it would have been valuable to me a couple of weeks ago.

(Btw, I'm certainly guilty of the same thing myself - there's always "a few more things" that I want to get done before I call nrdo (http://savannah.nongnu.org/projects/nrdo) "version 0.1" or whatever. But since nobody but me is actually using nrdo at all, it doesn't affect anyone much ;) I also know that I'm wrong to do this and putting a version number on the current snapshot is one of my top priorities as soon as I find time to do a "release process".)