Lambda the Ultimate

Nice, thanks for the links. Seems to be referred to as the binary method problem, where two parameters are of same type. As there does not seem to be an accepted convention for it I will need to come with my own (and look hard on whether I need exact types)

If the binary method problem is what you're looking into, Pierce's book "Types and Programming Languages" covers this. For public info, you can start with Pierce and Cardelli's On Binary Methods.

That is interesting as well.

In my case, I was looking at class methods rather than instance methods. On the other hand in the paper we have

class PointClass 
  instance variables 
    xValue: real 
    yValue: real 
  methods 
    x: real is return(xValue)
    y: real is return(yValue)
    equal(p: Point): bool is 
       return( (xValue==p.x) && (yValue==p.y) ) 
end class 

class ColorPointClass subclass of PointClass
  instance variables 
    -- xValue and yValue are inherited
    cValue: string
  methods 
    -- x and y are inherited
    c: string is return(cValue)
    -- equal is overriden
    equal(p: ColorPoint): bool is 
        return( (cValue==p.c) && (xValue==p.x) && (yValue==p.y) ) 
end class

If I make equal a class method it will look like

-- class PointClass
  class methods
    equal(p1, p2: Point): bool is 
       return( (p1.xValue==p2.xValue) && (p1.yValue==p2.yValue) )  

-- class ColorPointClass
  class methods
    -- equal is overriden
    equal(cp1, cp2: ColorPoint): bool is 
        return( (cp1.cValue==cp2.cValue) && (cp1.xValue==cp2.xValue) && (cp1.yValue==cp2.yValue) ) 

At this point the methods are invoked with a specific class so there is no binary method issue. But I would like to define them outside the class in a Qualifier (like a mixin):

qualifier Comparable
  class methods
    equal(p1, p2: SelfType): bool
end qualifier

class PointClass is Comparable
...
  class methods
    equal(p1, p2: SelfType): bool is 
       return( (p1.xValue==p2.xValue) && (p1.yValue==p2.yValue) )  
end class

class ColorPointClass subclass of PointClass
...
  class methods
    equal(cp1, cp2: SelfType): bool is 
        return( (cp1.cValue==cp2.cValue) && (cp1.xValue==cp2.xValue) && (cp1.yValue==cp2.yValue) ) 
end class

...
b: bool := Comparable.equal(p1, p2)

Which method should be called when doing Comparable.equal? It will depend on both arguments. So I guess that is a form of multimethod. But with that scheme it is not possible to redefine eg. equal(p: PointClass; cp: ColorPointClass): bool so that makes it more limited than CLOS multimethods.

That's the Curiously recurring template pattern:
http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern
however, if you have a more complex hierarchy, that doesn't work - you'd need ActualSubClass to take a parameter as well, and to have another real ActualSubClass.

template<typename MySubClass>
class MyClass {
  virtual MySubClass newInstance() = 0;
};
template<typename MySubClass>
class SubClass : public MyClass<MySubClass> {
  MySubClass newInstance() { ... }
};
class ActualSubClass: public SubClass<ActualSubClass> {
}
template <typename MySubClast>
class SubSubClass : public SubClass <MySubClass> {
  MySubClass newInstance() { ... }
};

class ActualSubSubClass: public SubSubClass <ActualSubSubClass> {
}

Now, however, you miss some interesting subtyping relationship. Maybe that could be fixed with multiple inheritance, with virtual inheritance to avoid duplication of the same supertype - but probably not, because templates are invariant. ActualSubSubClass descends from SubSubClass<ActualSubSubClass>, and therefore from SubClass<ActualSubSubClass>(=typeA), which is unrelated to SubClass<ActualSubClass> (=typeB) == ActualSubClass. Therefore, one would get an instance of typeA and one of typeB, even with virtual inheritance.