On Tuesday, 18 July 2017 at 18:03:30 UTC, jmh530 wrote:
On Tuesday, 18 July 2017 at 16:57:30 UTC, Ali Çehreli wrote:


Perhaps they are all needed but I'm thinking about the need for forward declaration, the need for the underscore prefix, etc.


He might be able to at least get rid of the forward declaration (not sure on the underscore).

The way it works now is that a class that inherits from an interface is not required in any way to implement the methods. Suppose he adds another attribute to an interface such that any class that inherits from it is required to have methods defined for specific functions.

So for instance, the Matrix example might look something like

@trait
interface Matrix
{
  @property int rows() const;
  @property int cols() const;
  @property double at(int i, int j) const;
  @trait void print();
}

I'm not sure this would work because anything that derives from Matrix must implement print. However, if it is possible to use the attribute to allow the derived classes to ignore print, then it might work. Alternately, if there is a way to process the interface and tell the compiler to somehow ignore the @trait member functions. I don't know if it'll work, but it's an idea.

Anyway, the mixin(registerMethods); could then be adjusted so that void print(virtual!Matrix m); is mixed in automatically because we now know how to construct it.

There are at least problems with this. Firstly it is intrusive - something I strive to avoid (although I could be 100% orthogonal only because I hijack a deprecated pointer in ClassInfo). Also, some methods may want to treat Matrix as a virtual argument, and some not.

Look at https://github.com/jll63/methods.d/blob/master/examples/matrix/source/matrix.d and https://github.com/jll63/methods.d/blob/master/examples/matrix/source/densematrix.d They know nothing about printing. They don't want to. The matrix modules do math, the app does printing.

J-L

Reply via email to