Open Methods: From C++ to D

[EntangledQuanta via Digitalmars-d-announce]

On Saturday, 2 September 2017 at 21:16:50 UTC, Jean-Louis Leroy 
wrote:
> On Saturday, 2 September 2017 at 20:55:13 UTC, EntangledQuanta 
> wrote:
>
>> This is when I have the mixin(registerMethods) in a module 
>> that doesn't use any open methods. It says add once per module 
>> in the help, but I think it means once per module where open 
>> methods are used?
>
> Yes I meant that. The README.md says "Every module that 
> declares methods or define implementations must include the 
> following line". Ah yes the ddoc. I should update it.
>
> Also I think I should allow the mixin to silently do nothing in 
> this case. Good catch.
>
>> You might look in to adding updateMethods in a static this() 
>> since it will be ran per process and do everything necessary, 
>> I think.
>
> Alas it won't work. Method registration is done via static 
> ctors and they have to run - all of them - before updateMethods 
> can do its work. In simple, one-module programs updateMethods 
> in a static ctor will work, but in general it won't.
>

hmm, surely there is a mechanism which can be used? Possibly 
hooking in to druntime or some other hack? Not that it's a big 
deal but if you could get off the dependencies then it would be a 
sort of "compiler solution".

>> Strangely enough, I had a protected member that I was using 
>> and it works, I guess because I defined the openmethod in the 
>> same module. I changed it to private and it worked too. So the 
>> issues about encapsulation I thought about before may be 
>> irrelevant as long as the openmethods are used in the same 
>> module(which is a nice feature of D).
>
> Neither the methods nor their overrides enjoy special 
> privileges. Unless the override (i.e. the thing preceded by 
> @method) is a static member function? But I don't think so. 
> Currently my code just scans the direct member of the module in 
> which mixin(registerMethods) is called. Although I could change 
> that, thus giving privileged access to some overrides. Could be 
> useful for 1-methods.
>
> But anyway, probably there's something you don't 
> notice...hmmm...can you share that code?
>

In D, encapsulation is voided at the module level. So private 
members are public to the module.

struct S { private int x; }

void foo(S s) { writeln(s.x); }

works. If foo is declared outside the module it will fail.

It's like friend in C++ but automatic and per module. Pretty nice 
but that is about as far as it goes in D.

My code was pretty simple. I couldn't share it all because it's 
too large, but I simply replaced a single member with an open 
method. It had a few lines of code. One was accessing a protected 
member, which I changed to private... all compiled. Then I 
remembered about D's encapsulation rules for the module. So that 
nullified my issues that I though openmethods might have.

So, I think, in fact, this might be a pretty good solution to 
many problems. It allows extensibility without tying the methods 
to the classes directly. I'm still imagine encapsulation will be 
an issue for larger designs since the openmethods won't be 
defined in the same module, but I haven't used them enough to 
know what kinda faults will creep up yet.

I haven't used openmethods enough to really see their power but 
hopefully with this solution I can ;) Thanks!