Jean-Louis Leroy posted about his open methods library here in the forums some time ago. Now, he's written a blog post that explains what open methods are, and describes the D implementation and how it compares to his C++ library.

The blog:
https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/

Reddit:
https://www.reddit.com/r/programming/comments/6wj0ev/open_methods_from_c_to_d/

On 28/08/2017 1:19 PM, Mike Parker wrote:
> Jean-Louis Leroy posted about his open methods library here in the forums some time ago. Now, he's written a blog post that explains what open methods are, and describes the D implementation and how it compares to his C++ library.
> 
> The blog:
> https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/
> 
> Reddit:
> https://www.reddit.com/r/programming/comments/6wj0ev/open_methods_from_c_to_d/ 

Neat. Good to see articles in support of TypeInfo/ClassInfo!
I do wish we extended it for full reflection capabilities though...

On Monday, 28 August 2017 at 12:31:20 UTC, rikki cattermole wrote:
> On 28/08/2017 1:19 PM, Mike Parker wrote:
>> Jean-Louis Leroy posted about his open methods library here in the forums some time ago. Now, he's written a blog post that explains what open methods are, and describes the D implementation and how it compares to his C++ library.
>> 
>> The blog:
>> https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/
>> 
>> Reddit:
>> https://www.reddit.com/r/programming/comments/6wj0ev/open_methods_from_c_to_d/
>
> Neat. Good to see articles in support of TypeInfo/ClassInfo!
> I do wish we extended it for full reflection capabilities though...

Agreed.

Andrei suggested using rtlInfo but AFAICT this requires building a custom druntime. It would be easy to support this method in addition to 'deallocator' and 'hash' but I suspect it would not be a very popular option.

Maybe we could have a void*[] in TypeInfo and a global integer index that extensions could use to allocate entries?

On 28/08/2017 9:06 PM, Jean-Louis Leroy wrote:
> On Monday, 28 August 2017 at 12:31:20 UTC, rikki cattermole wrote:
>> On 28/08/2017 1:19 PM, Mike Parker wrote:
>>> Jean-Louis Leroy posted about his open methods library here in the forums some time ago. Now, he's written a blog post that explains what open methods are, and describes the D implementation and how it compares to his C++ library.
>>>
>>> The blog:
>>> https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/
>>>
>>> Reddit:
>>> https://www.reddit.com/r/programming/comments/6wj0ev/open_methods_from_c_to_d/ 
>>>
>>
>> Neat. Good to see articles in support of TypeInfo/ClassInfo!
>> I do wish we extended it for full reflection capabilities though...
> 
> Agreed.
> 
> Andrei suggested using rtlInfo but AFAICT this requires building a custom druntime. It would be easy to support this method in addition to 'deallocator' and 'hash' but I suspect it would not be a very popular option.
> 
> Maybe we could have a void*[] in TypeInfo and a global integer index that extensions could use to allocate entries?

Instead of hacking new features in, we should work on a full redesign.
Clearly its needed between TypeInfo not cross the dll boundary on Windows (yay no classes!), -betterC and of course full reflection that we can do significantly better in this department.

On Monday, 28 August 2017 at 12:19:26 UTC, Mike Parker wrote:
> Jean-Louis Leroy posted about his open methods library here in the forums some time ago. Now, he's written a blog post that explains what open methods are, and describes the D implementation and how it compares to his C++ library.
>
> The blog:
> https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/
>
> Reddit:
> https://www.reddit.com/r/programming/comments/6wj0ev/open_methods_from_c_to_d/

Nice. This does seem superior to the visitor pattern.

On Tuesday, 29 August 2017 at 12:09:01 UTC, Mark wrote:
> Nice. This does seem superior to the visitor pattern.

Here is another example - AST traversal: https://github.com/jll63/openmethods.d/blob/master/examples/acceptnovisitors/source/app.d

On Tuesday, 29 August 2017 at 12:45:50 UTC, Jean-Louis Leroy wrote:
> On Tuesday, 29 August 2017 at 12:09:01 UTC, Mark wrote:
>> Nice. This does seem superior to the visitor pattern.
>
> Here is another example - AST traversal: https://github.com/jll63/openmethods.d/blob/master/examples/acceptnovisitors/source/app.d

Thanks for this library. Just a suggestion. Would it possible to use `@openmethod` instead of `@method`?

On Wednesday, 30 August 2017 at 04:48:11 UTC, Arun Chandrasekaran wrote:
> On Tuesday, 29 August 2017 at 12:45:50 UTC, Jean-Louis Leroy wrote:
>> On Tuesday, 29 August 2017 at 12:09:01 UTC, Mark wrote:
>>> Nice. This does seem superior to the visitor pattern.
>>
>> Here is another example - AST traversal: https://github.com/jll63/openmethods.d/blob/master/examples/acceptnovisitors/source/app.d
>
> Thanks for this library. Just a suggestion. Would it possible to use `@openmethod` instead of `@method`?

Ah, I think it's a little late for that. A while ago I asked if anyone had suggestions regarding that sort of things...But now that the article has been published I think it would be a very bad idea to break all the exmaples in it.

What was your rationale for `openmethod` instead of just `method`?

I will push a commit tonight that will make this work:

  import openmethods : virtual, openmethod = method, next, registerMethods, updateMethods;

  // ...

  @openmethod // implement 'kick' for dogs
  string _kick(Dog x) // note the underscore
  {
    return "bark";
  }

On Wednesday, 30 August 2017 at 13:35:22 UTC, Jean-Louis Leroy wrote:
> On Wednesday, 30 August 2017 at 04:48:11 UTC, Arun What was your rationale for `openmethod` instead of just `method`?

Just that `openmethod` precisely expresses it's intent and `method` is too generic.

On Wednesday, 30 August 2017 at 14:37:14 UTC, Arun Chandrasekaran wrote:
> On Wednesday, 30 August 2017 at 13:35:22 UTC, Jean-Louis Leroy wrote:
>> On Wednesday, 30 August 2017 at 04:48:11 UTC, Arun What was your rationale for `openmethod` instead of just `method`?
>
> Just that `openmethod` precisely expresses it's intent and `method` is too generic.

I sort of agree, and somewhat regret not picking 'openmethod'. I considered both. Also @specialize. If anyone had pushed for @openmethod before the article, I would almost certainly have given in.

My reasoning was, I hope to promote the term 'method' as the standard name for polymorphism from outside, as opposed to vfunc. We usually say "virtual functions", rarely "virtual member functions". Membership is implicit.