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!
