www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - openmethods 1.3.0

reply Jean-Louis Leroy <jl leroy.nyc> writes:
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
Apr 19
next sibling parent Jean-Louis Leroy <jl leroy.nyc> writes:
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
Apr 19
prev sibling parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2020-04-19 13:13:55 +0000, 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
Apr 20
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
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.
Apr 20
prev sibling parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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'.
Apr 20
parent jmh530 <john.michael.hall gmail.com> writes:
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'.
would have to be part of the language itself to remove mixin(registerMethods).
Apr 20