On Thursday, 31 August 2017 at 20:42:36 UTC, EntangledQuanta wrote:
On Wednesday, 30 August 2017 at 18:16:47 UTC, jmh530 wrote:
On Wednesday, 30 August 2017 at 15:59:32 UTC, Jean-Louis Leroy wrote:
What happens here is that kick(Animal) is shadowed by kick(Dog). kick(Animal) is a method but it appears to the user and the compiler as an ordinary function - which is generally good. As such it is eligible for UFCS. I would not recommend this sort of coding, but it's everyone's choice, methods or not.

Likewise, methods can be overloaded (like here https://github.com/jll63/openmethods.d/blob/1.0.0-rc.1/examples/matrix/source/matrix.d#L12).

A current limitation is that default arguments are not supported (yet), although I think it's just a matter of putting the effort in.

UFCS interacts nicely with methods because you can say a.plus(b) even if 'plus' is an open method.

I can submit this as an issue on the github page, but I figured I'd mention it here in case there was some easy fix.

I tried installing the latest release from github. Compiling (Windows 7 on DMD with default options) the simple program below

import openmethods;
mixin(registerMethods);

void main()
{
}

gives me the errors:

..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(970,21): Error: ca
nnot implicitly convert expression h of type ulong to uint
..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(1076,34): Error: c
annot implicitly convert expression dim of type ulong to uint
..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(1177,23): Error: c
annot implicitly convert expression h of type ulong to uint
dmd failed with exit code 1.

The error at line 1076 can be fixed by changing the type of dim in the function to size_t. I couldn't fix the other errors. I tried having the hash function return size_t also, but that just causes other problems.

I was getting similar errors and simply added a cast(size_t)[used in the indexing, as he used ulongs for indexes rather than size_t] to all those you mention. After that I got more errors that I can't recall now but was much more cryptic. I did updateMethods and added the mixin but things wern't working so I gave up. Seems like a nice idea, although, the downside that I see is one doesn't get encapsulation.

It's fixed now, in master and in release v1.0.0-rc.2.

Actually not getting encapsulation is good. With vfuncs, if you want polymorphism you get access to private parts, need it or not. And most of the time you neither need nor want it.

If you need polymorphism and privileged access, you should use a vfunc but it's usually a sign of bad design, because a vfunc is meant to be overridden. And the override won't have access to the private parts so you may end up changing access from private to protected and usually trouble follows.

I can imagine legitimate cases though. Fox example, the DiagonalMatrix addition example. In that case you can write a public final member function that performs addition using privileged access and call that from the 2-method 'plus'.



ANother approach is to write the fvunc - or the 1-method - in terms of the public interface. Usually it's feasible and yields a better design.

Reply via email to