On Tuesday, 18 July 2017 at 18:21:21 UTC, Ali Çehreli wrote:
> On 07/18/2017 11:03 AM, jmh530 wrote:
>
> > the mixin(registerMethods); could then be adjusted so that
> void
> > print(virtual!Matrix m); is mixed in automatically because we
> now know
> > how to construct it.
>
> That reminds me: Would the following be possible and better?
>
> // From
> void main()
> {
>   updateMethods();
>   // ...
> }
>
> // To
> mixin(constructMethods());
> void main()
> {
>   // ...
> }
>
> constructMethods() could return the following string:
>
> string constructMethods() {
>   return q{
>     shared static this() { updateMethods(); }
>   };
> }

OK, I think I may have found solutions to both problems. The question is, is it too hacky?

1/ method registration

Replace this:

  import openmethods;
  mixin(registerMethods);

...with:

  mixin(import(openmethoddecls));

...that does the two above. Problem is, it needs -Jpath on the command line to work. Unless there is a workaround?

2/ updateMethods

During static construction, I could set the dispatch tables to make all the methods call a function that does updateMethods() then re-dispatches. The cost of the first method call would be huge, but if it matters the user can still call updateMethods explicitly.

Thoughts?

On Wednesday, 19 July 2017 at 12:29:36 UTC, Jean-Louis Leroy wrote:
>
> ...that does the two above. Problem is, it needs -Jpath on the command line to work. Unless there is a workaround?
>

I prefer the original.

On Wednesday, 19 July 2017 at 13:35:40 UTC, jmh530 wrote:
> On Wednesday, 19 July 2017 at 12:29:36 UTC, Jean-Louis Leroy wrote:
>>
>> ...that does the two above. Problem is, it needs -Jpath on the command line to work. Unless there is a workaround?
>>
>
> I prefer the original.

What if you do:

shared static this(){

  mixin(registerMethods);

}

On Wednesday, 19 July 2017 at 13:36:55 UTC, jmh530 wrote:
> On Wednesday, 19 July 2017 at 13:35:40 UTC, jmh530 wrote:
>> On Wednesday, 19 July 2017 at 12:29:36 UTC, Jean-Louis Leroy wrote:
>>>
>>> ...that does the two above. Problem is, it needs -Jpath on the command line to work. Unless there is a workaround?
>>>
>>
>> I prefer the original.
>
> What if you do:
>
> shared static this(){
>
>   mixin(registerMethods);
>
> }

You mean in openmethods.d?

On Wednesday, 19 July 2017 at 13:46:24 UTC, Jean-Louis Leroy wrote:
>>
>> What if you do:
>>
>> shared static this(){
>>
>>   mixin(registerMethods);
>>
>> }
>
> You mean in openmethods.d?

Yes. I haven't tried something like that, but it seems like a use case for either static this or shared static this.

https://dlang.org/spec/class.html#StaticConstructor
https://dlang.org/spec/class.html#SharedStaticConstructor

On Wednesday, 19 July 2017 at 15:33:28 UTC, jmh530 wrote:
> On Wednesday, 19 July 2017 at 13:46:24 UTC, Jean-Louis Leroy wrote:
>>>
>>> What if you do:
>>>
>>> shared static this(){
>>>
>>>   mixin(registerMethods);
>>>
>>> }
>>
>> You mean in openmethods.d?
>
> Yes. I haven't tried something like that, but it seems like a use case for either static this or shared static this.
>
> https://dlang.org/spec/class.html#StaticConstructor
> https://dlang.org/spec/class.html#SharedStaticConstructor

Among other things, the mixin introduces two functions in the module's scope: the function the user actually calls (the "dispatcher"). E.g. it creates a times(double, Matrix) when it sees a times(double, virtual!Matrix). It also declares a "discriminator" function which is used to locate which method the specializations (the @method funcs) relates to (it has to deal with overloads - there are two "times" methods). This has to be done for every module that contains method declarations (virtual!) or implementations (@method). That's why it has to be a string mixin (at least until we have static foreach) and be called in the matrix etc modules, not in module openmethods.

On Wednesday, 19 July 2017 at 15:33:28 UTC, jmh530 wrote:
>
> Yes. I haven't tried something like that, but it seems like a use case for either static this or shared static this.
>
> https://dlang.org/spec/class.html#StaticConstructor
> https://dlang.org/spec/class.html#SharedStaticConstructor

Based on some of your README.md text, you may need to do static this rather than shared static this for what I suggested. I don't really know, but worth investigating.

I liked Ali's suggestion for mixin updateMethods. Again, not sure if it should be static this or shared static this, but if you have static this for registerMethods, then a shared static this for updateMethods may occur before that. I'm not sure how important the order is.

On Wednesday, 19 July 2017 at 15:56:06 UTC, Jean-Louis Leroy wrote:
>
> Among other things, the mixin introduces two functions in the module's scope: the function the user actually calls (the "dispatcher"). E.g. it creates a times(double, Matrix) when it sees a times(double, virtual!Matrix). It also declares a "discriminator" function which is used to locate which method the specializations (the @method funcs) relates to (it has to deal with overloads - there are two "times" methods). This has to be done for every module that contains method declarations (virtual!) or implementations (@method). That's why it has to be a string mixin (at least until we have static foreach) and be called in the matrix etc modules, not in module openmethods.

I see what you mean. It only works per thread, not per module.

What you really need is some kind of module constructor.