Static inheritance of an interface

The more I dive into implementing Skila the more I appreciate the role of the type system. Yet another interesting case is with generics — how to make them compile-once and be efficient for both complex and native types? Say, you would like to implement “Vector<T>” — one operation which has to be executed is copying the value.

In C++ world you define template and when using it, given type appears viable (or not), however it goes with the price of compilation of each instantiation of the template. In C# you can specify constraint that “T” has to inherit from something like “ICopyable”. But native types do not inherit from anything, so how to make them fit into a template?

I noticed that generics supports object oriented programming, but is not dependent of it. So sure, you can express such constraint, but you can specify another one — making “T” to provide all methods (or extension functions) declared in “ICopyable”.

This makes type such as “Int” fit for “Vector”:

class Vector<T>
  where T : static ICopyable;
...

Note the keyword “static”, “T” is no longer checked against given inheritance, but against providing a set of methods.

The methods are checked when “Vector” is instantiated, if you would like to make the code more explicit specify static inheritance when defining the class:

class Foo : static ICopyable
...

This does not add regular inheritance, instead it enforces the given suite of the methods when defining the class “Foo”, not when calling for “Vector<Foo>”.

Advertisement

Heavy lifting with interfaces

Once I touched the interfaces subject it seems the time it was sufficient to change a syntax a bit to make some progress passed away — this weekend I finished overloading, next time I plan to tackle overriding.

I barely had time to make minor adjustments:

• interface name has to start with capital letter “I” (it is a requirement, not a convention),
• the root type in Skila is “IObject”,
• there is multiple type inheritance (one class + multiple interfaces),
• I reversed and shortened Ruby syntax for mutators — “x!ChangeMe()” instead “x.ChangeMe!()”,
• and I made “Void” result type optional when declaring or defining a function — so it is more like Pascal procedure.

Once I deal with interfaces I have to redo almost entire backend — so far I relied on PHP classes but I think this won’t pay off. First of all PHP has only virtual methods, so it is a dead end for me no matter how I look at it. The second reason is JavaScript — its object model is so different, that sooner or later I would have to find common denominator among backend languages to save my time. I think I should be safe with using just structures, standalone functions and custom dispatcher.