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,
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
@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
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
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.