Re: openmethods 1.3.0
On Monday, 20 April 2020 at 13:25:14 UTC, Jean-Louis Leroy wrote: [snip] That is not a problem. If I was granted two wishes, they would be: 1/ reallocate 'ClassInfo.deallocator' to me ;-) and 2/ add a more general feature to the language, similar to Perl's 'import' function: if a module defines a 'string imported(alias Module)' or a 'mixin template imported(alias Module)', call it in the context of the importing module. That would allow me to get rid of the 'mixin(registerMethods)' after the 'import openmethods'. I'm skeptical Walter will ever allow something like #2. Probably would have to be part of the language itself to remove mixin(registerMethods).
Re: openmethods 1.3.0
On Monday, 20 April 2020 at 08:17:24 UTC, Robert M. Münch wrote: I just read your blog post [1] and wonder if it's still up-to-date or maybe an update would make sense? The blog post is still current. I remember that, in 2017, some were annoyed by the need to call a setup function (updateMethods). As for support for attributes, it is nice to have, but it is hardly the focus of the module. I don't think the improvements deserve a new blog entry. However, in the process of implementing support for attributes and storage classes, the internals became very ugly. Also I had a to address the same problems in a new library. Eventually I found a way of factoring the mixin generation code in a package that I am going to spin off, probably as part of bolts. But I need permission from my employer to do that. I hope to get it soon. This stuff sounds like a very fundamental concept/pattern and IMO would be a good member of Phobos. Andrei is not convinced ;-) Well at least not as part of the language, but probably not as part of Phobos either. That is not a problem. If I was granted two wishes, they would be: 1/ reallocate 'ClassInfo.deallocator' to me ;-) and 2/ add a more general feature to the language, similar to Perl's 'import' function: if a module defines a 'string imported(alias Module)' or a 'mixin template imported(alias Module)', call it in the context of the importing module. That would allow me to get rid of the 'mixin(registerMethods)' after the 'import openmethods'.
Re: openmethods 1.3.0
On Monday, 20 April 2020 at 08:17:24 UTC, Robert M. Münch wrote: [snip] This is very interesting stuff! Thanks a lot. I just read your blog post [1] and wonder if it's still up-to-date or maybe an update would make sense? This stuff sounds like a very fundamental concept/pattern and IMO would be a good member of Phobos. [1] https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/ Definitely interesting stuff. Glad to see that the infrastructure is improved.
Re: openmethods 1.3.0
On 2020-04-19 13:13:55 +, Jean-Louis Leroy said: You can read more about openmethods on githubL https://github.com/jll63/openmethods.d This is very interesting stuff! Thanks a lot. I just read your blog post [1] and wonder if it's still up-to-date or maybe an update would make sense? This stuff sounds like a very fundamental concept/pattern and IMO would be a good member of Phobos. [1] https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/ -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: openmethods 1.3.0
On Sunday, 19 April 2020 at 13:13:55 UTC, Jean-Louis Leroy wrote: You can read more about openmethods on githubL https://github.com/jll63/openmethods.d Available on DUBS here: https://code.dlang.org/packages/openmethods
openmethods 1.3.0
This release implements support for function attributes, except for `pure`. User-defined attributes on methods and method parameters are also supported. It is no longer necessary to call `updateMethods` explicitly, except after dynamically loading or unloading shared libraries. The internals got a major cleanup. All the mixin generating code has been moved to a separate set of modules, which I plan to contribute to the bolts library. You can read more about openmethods on githubL https://github.com/jll63/openmethods.d
