# Friday, 17 October 2003
« GNU Classpath Meeting | Main | Private Super Classes »
Ghosts

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.

Friday, 17 October 2003 15:57:05 (W. Europe Daylight Time, UTC+02:00)  #    Comments [2] Tracked by:
"diet pills to help lose weight" (diet pills to help lose weight) [Trackback]