Runtime dependency checking

[Frustrated]

http://dpaste.dzfl.pl/80c6225ed090

The code above demonstrates run-time contracts using interface 
based programming.

It provides two co-benfits: Simplified class implementation(you 
do not have to use interfaces for types which then requires 
casting that type for orthogonal behavior) and run-time contracts.

e.g., The WindowsGui class is implemented using WindowsButton and 
not iButton. This allows one to avoid having to cast the iButton 
to a WindowsButton when one wants to use the featuers of a 
WindowsButton.

A contract is created that every iButton used in WindowsGui must 
be a WindowsButton or an error is thrown. This creates a run-time 
contract or dependency between WindowsGui and WindowsButton. 
Normally in such interface based programming the contract is not 
automatic and any iButton(for example, a linux button) could be 
used for the WindowsGui. Normally this is not desired behavior as 
it limits what WindowsGui can do.


Basically when we "lift" a class to an interface and any objects 
used in that class to interfaces we create contract that is in 
general too generic(but easier to specify in the language). This 
creates generally creates a problem for the implementations of 
the interface by forcing them to be more generic than one wants. 
To solve this requires casting and type checking to get the more 
specific type. The mixin attempts to automate this. It would be 
nice if the language was extended to allow covariance on argument 
types, e.g.,

interface iGui
{
     @property T button(T : iButton)(T button); // Syntax says 
that any T can be used as long as it is derived from 
iButton(instead of just an iButton)
}

class WindowsGui : iGui
{
     @property WindowsButton button(WindowsButton  button) { }
     // implements the iGui.button property since it satisfies the 
contract and also allows us to use the type we actually want to 
use. (no explicit casts or checks)
}

Now, WindowsGui.button might be used with an iButton, so an 
implicit check is required to make sure that iButton is of 
WindowsButton type.

The compiler could handle this quite easily. The mixin emulates 
such a feature. The mixin is not robust though.

I seriously doubt that we'll ever get the semantics to handle 
this though.


In any case, I think there is real benefit here and it makes it 
easier to do modular programming in D with proper dependency 
checking(WindowsGui is dependent on WindowsButton, not iButton or 
LinuxButton and this dependency is retained even when we use the 
iGui and iButton interface).

Now, in the meantime I'll work on tidying up the mixin code but I 
was thinking about adding versioning. I could have a version 
property in all the types only if the versions have the same 
major version are they compatible. So a WindowsGui 3.42 is not 
compatible with a WindowsButton 2.89. Not sure if this a good way 
or if it will cause headaches later on. (I could keep a file of 
all the version compatibilities but that seems excessive)

Any ideas?


---- output ----
Trying WindowsButton with WindowsGui!
Do(): WindowsButton
WindowsButton.foo(): I'm an extra WindowsButton feature!
...WindowsButton works in WindowsGui!
Trying WindowsBorder with WindowsGui!
Do(): WindowsBorder
WindowsBorder.foo(): I'm an extra WindowsBorder feature!
...WindowsBorder works in WindowsGui!

Trying LinuxBorder with WindowsGui!
Invalid object type dependency mismatch! Type: f872.LinuxBorder 
Type Expected: WindowsBorder


Trying LinuxButton with WindowsGui!
Invalid object type dependency mismatch! Type: f872.LinuxButton 
Type Expected: WindowsButton


Trying WindowsButton with LinuxGui!
Invalid object type dependency mismatch! Type: f872.WindowsButton 
Type Expected: LinuxButton

Trying LinuxButton with LinuxGui!
Do(): LinuxButton
...LinuxButton works in LinuxGui!
Trying WindowsBorder with LinuxGui!
Invalid object type dependency mismatch! Type: f872.WindowsBorder 
Type Expected: LinuxBorder

Trying LinuxBorder with LinuxGui!
Do(): LinuxBorder
...LinuxBorder works in LinuxGui!