I just pushed a change that fixes a long-standing problem with interfaces.
Interfaces are implemented as ordinary annotations. When the @interface
annotation is used, it expands a definition of a class derived from
VTableBase. This lets us mix the interface in with arbitrary base classes
and also lets us define a class with multiple interfaces (diamond inheritance,
where a class inherits from multiple base classes with a common ancestor
class, is not allowed in Crack except for the VTableBase class, so interfaces
can not be derived from Object which classes are by default).
We could just derive from VTableBase except that we still need the reference
counting mechanism defined in Object. For example:
class A {}
class B : VTableBase {}
class C : A, B {}
C c = {};
B b = c;
c = null;
In the example above, when 'c' is assigned to null, the reference count of its
object drops to 0 and the object is deleted because B doesn't have bind and
release operators or a reference count. 'b' now points to unmanaged memory.
Part of what @interface does is to generate bind and release operators that
delegate to Object.oper bind() and Object.oper release(). But to be able to
ues these, we need a way to convert the interface to the Object that its
implementation class will be based on.
As a hack, the code used to generate a special method:
_iface_get$(Interface)Object() ($(Interface) was the name of the interface
class). This was abstract in the interface and defined in the implementation
to simply "return this," allowing us to do the conversion. But _iface_get*
had some problems because it was based on the simple class name. So:
- Aliasing interfaces didn't work, because "@implements Alias" caused
_iface_getAliasObject() methods to be generated instead of
_iface_getRealClassNameObject() methods.
- You couldn't implement two different interfaces with the same simple name,
for example Functor1[void, int] and Functor1[void, String] (for generics,
we only used the name of the generic class, not the instantiation class).
The solution to this is the special "oper from ClassName" operator. Like
"oper to", "oper from" is implemented in the parser and has full knowledge of
the type that is specified. Therefore, it can implement the operator based on
the canonical name of the type, solving the problems above.
I originally considered creating a more complete implementation of virtual
base classes, but with "oper from", I no longer see a use case for it.
I think that everything that you can do with a virtual base class you can also
do with "oper from" and annotations.
Of course, I'm open to a counterexample.
