Access modifier for extensions

Rikki Cattermole alphaglosined at gmail.com
Thu Jan 16 02:22:39 PST 2014


Something that I have been doing quite heavily recently is a 
registration approach. I.e. in a module constructor (shared) you 
call a function giving it a class type that most likely inherits 
another class/interface. From there code is generated/executed at 
compile time for that function call. Very useful for registering 
e.g. routes.

However an issue with this approach I've seen while porting glfw 
to D is that sure this works but how can I do e.g. new 
Window(640, 480, "My title here"); when it needs to hook into the 
registration system to grab the real window implementation that 
you have set to use by default (or overridable by adding the name 
to the call).

This is essentially the factory pattern.

Now something that allows me to say the function allocates this 
class but not its children would really be useful. As I could get 
it to go to the registration system and grab the allocated result 
from there.

Based upon this what you're thinking of is essentially 
add/override methods on a class which is really isn't good D 
code. Too much like c++ and ugly.
Perhaps what we could have to accomplish your part while making 
it obvious is a sorta like how c#'s event support is.

Now we could implement this as a mixin template. I.e. it could 
generate:

static void method_addHandler(T)(del)
in {
  ... // check if del is a delegate with matching definition
  // first arg must be previous value
} body {
  ... // add arg to list
}

T method(ARGS) {
  ... // run handlers while passing previous value
}

With this you could also pass e.g. a lambda or some delegate to 
the mixin to say this is my default output of this method. Can 
also do some checks for default return types ext.

I don't know how to handle access modifiers for this. However 
pretty much everything else is doable without changing the front 
end specially for this use case. Will depend though on the 
allocation api and if it'll allow you to return a child class 
type. I don't see why it wouldn't though.

But this is just my thoughts on the matter. I'm sure somebody 
will destroy it!


More information about the Digitalmars-d mailing list