Open Methods: From C++ to D

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

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.

> 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?

Thanks for the feedback.