It took a bit longer than I anticipated, but I finally managed to put together a new
snapshot and check in the changes I made in last month and a half.
What's new?
-
Fixed bug in class load failure diagnostics code.
-
Instead of having a single Type property on TypeWrapper, we now have different properties
for different usages. I already know this isn't the final way I'm going to handle
things, but for now it is a nice improvement that makes it easier to treat types differently
based on where they are appearing (e.g. field, local, argument, base type).
-
Simple ghost references are translated as value type wrappers. See below for details.
-
Reflection support for ghost types.
-
Fixed a few ILGenerator.Emit() bugs where incorrect argument types were passed (int
instead of short or byte).
-
Added a NoPackagePrefixAttribute to allow .NET types to not be prefixed with the "cli"
prefix. (Suggested by Stuart Ballard)
-
Fix to prevent non-public delegates from being visible.
-
Several fixes in the handling of unloadable types.
-
Fixed java.lang.Comparable interface and method attributes to be identitical
to the real interface.
-
Fixed java.lang.Runtime.exec() support for quoted arguments.
Ghost References
First of all, why did I feel the need to change it? Imagine that java.lang.StringBuffer
had the following methods:
public void append(Object o) { ... }
public void append(CharSequence cs) { ... }
Previously, CharSequence would be erased to Object, so you'd have two methods
with an identical signature, thus requiring name mangling. Using the method from C#
would become very inconvenient, both because of the unexpected name, but also because
of the fact that it isn't at all clear what argument type is expected (and passing
an incorrect type will give odd results, like ClassCastException or IncompatibleClassChangeError).
Enter the value type wrapper. Here is how the java.lang.CharSequence interface is
compiled now (pseudo code):
public
struct CharSequence {
public interface __Interface
{
char charAt(int i);
// ... other methods ...
}
public object __ref;
public static CharSequence Cast(object o)
{
CharSequence s;
if(o is string)
{
s.__ref = o;
return s;
}
s.__ref = (__Interface)o;
return s;
}
public static bool IsInstance(object o)
{
return o is string ||
o is __Interface;
}
public object ToObject()
{
return __ref;
}
public static
implicit operator CharSequence(string s)
{
CharSequence seq;
seq.__ref = s;
return seq;
}
public char charAt(int i)
{
if(__ref is string)
{
return StringHelper.charAt((string)__ref,
i);
}
return ((__Interface)__ref).charAt(i);
}
// ... other methods ...
}
All types that implement CharSequence will be compiled to implement CharSequence.__Interface
and will also get an implicit conversion operator to convert to CharSequence. This
allows C# code to easily call any methods that take a CharSequence argument,
because any valid type will be implicitly convertible to the CharSequence value type.
What Are The Downsides?
There are a few cons:
-
This trick doesn't work for arrays. So a CharSequence[] is still compiled as Object[].
Hopefully arrays are far less common, so this will not be a big issue.
-
C# code implementing CharSequence, needs to implement CharSequence.__Interface and
also needs to provide an implicit conversion operator to the CharSequence value type.
-
The static methods Cast and IsInstance need to be used instead of the normal language
features.
-
It is very easy to accidentally box the CharSequence value type in C#, when you pass
this to Java things will get very confusing. The proper way to convert CharSequence
to Object is by calling ToObject() on it.
Update: I forgot to mention that the reason that you have to implement
the implicit conversion on all types that implement the interface is because C# doesn't
allow implicit conversion from/to interfaces, otherwise the CharSequence value type
could just have an implicit conversion from CharSequence.__Interface and we'd be done.
Funnily enough, while C# doesn't allow you to define them, it turns out it does consume
them, but I don't know if this is guaranteed behavior or a bug. I need to find this
out. If it turns out to be correct, then I'll add the implicit conversion operator
to the value types, that makes life for C# implementers a tiny bit easier.
All in all, I think this is an improvement, but obviously not perfect. As always,
feedback is appreciated.
The new snapshots: binaries and complete.