On Thursday, 31 August 2017 at 20:42:36 UTC, EntangledQuanta
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
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
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
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
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