Open Methods: From C++ to D

[Jean-Louis Leroy via Digitalmars-d-announce]

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.