Extending generic types with traits

I am pretty happy I managed to add the feature I was not able to while working on previous Skila — traits. Initially I thought about them as conditional methods:

class Greeter<T>
{
  void hello(T &t) where T : ISay
  {
    t.say();
  }
}

But when reading “Programming Rust” I noticed that syntax for Rust type implementations and this gave me the idea of decoupling those “conditional methods” from the main type:

class Greeter<T>
{
}

trait Greeter<T>
  where T : ISay
{
  void hello(T &t) 
  {
    t.say();
  }
}

It looks very much like extension method however you can spice it with inheritance:

class Greeter<T>
{
}

trait Greeter<T> : ISay
  where T : ISay
{
  void hello(T &t) 
  {
    t.say();
  }
  // traits support polymorphism
  override void say()
  {
    println("just saying");
  }
}

Depending which type you pass when constructing Greeter it will inherit from ISay or not.

At this point there is a little zoo in Skila with similar features — protocols and interfaces, traits and extensions (upcoming) — and I hope some of them will be merged. Simplicity matters.

Advertisement

Generic static fields — see you next year

I wanted to make a mental note at the end of 2015 — “feature freeze”. It won’t happen, I cannot make my mind what is the right choice.

The natural decision would be to copycat C# — each constructed type has its own copy of static fields which allows to use generic static fields. Resharper wiki warns about this approach — “in the vast majority of cases, having a static field in a generic type is a sign of an error” ¹. We can find simpler one in Java (more for historical reasons than technical, but still) — it does not support generic static fields and it shares static fields among all constructed types. Scala takes another angle for the same model — since static data can live only in companion objects and they cannot have type parameters the issue is solved by design. As for Swift it is an open question because as the error message says static fields are “not yet supported in generic types”.

C# has some peculiarities — till now I didn’t figure out why C# makes instances of static constructor (see Accelerated C# 2010 by Trey Nash, p.263). Skila would have to add its own because of static variables in generic methods. I feel really insecure here so I wonder whether C# model is worth the effort?

A memento from C++ world:

The original intention of C++ template support envisioned a use-directed automatic instantiation mechanism that required neither user intervention nor multiple instantiations of the same file. This has proved considerably more difficult to achieve than anyone at the time imagined (see [STROUP94]).

— Stanley B.Lippman, Inside the C++ Object Model

Sure, it is not the same issue, over 22 years passed, nevertheless I still have the chills. Until I have firm knowledge or burning desire for this feature I’d better follow Swift footsteps — not supported. Yet.

---

¹ I was curious what “vast majority” means so I contacted the author of that entry, Dmitri Nesteruk. As it turned out it doesn’t translate to any numbers, it was just a generalization based on the nature of C# model.

What’s cooking — type generics and method’s zoo

I’ve just finished generics with type parameters, no surprise since I already implemented symbol generics. So far Skila does not have constraints, but I prefer to cover more ground in order to have working language in hand. Collections (and passing them around) is my next step.

Since this will take some time, I might make a break and add static virtual methods. You can say — “what? How a static method can be virtual”. Well, in C++/C# it cannot, because it was implemented that way. All it takes is one look from different perspective — take a regular virtual method and limit its access to static features only. Here you have it — static virtual method.

It is not a feature I will die for, but I too often bump into a problem which could be nicely solved having static virtual method and its cousin — pinned method (new concept), static or not. Pinned method is just like virtual one but it is erased with each new class in hierarchy, meaning once you add it somewhere you have to redefine it in each descendant class. This is pretty similar to pinned constructors (which are already implemented in Skila).

With such arsenal you can finally decide what is better for you, static factories or per instance, you can handle some traits of the class (type) with static methods. Nothing revolutionary, just more freedom and flexibility.

And since there is already so much variety why not add yet another one, with even more limited access — actually with no access at all. Function/method which relies only on its parameters with no side effects, pure function. We’ll see…