• Jean-Louis Leroy (10/10) Apr 19 2020 This release implements support for function attributes, except
• Jean-Louis Leroy (3/5) Apr 19 2020 Available on DUBS here:
• =?iso-8859-1?Q?Robert_M._M=FCnch?= (11/13) Apr 20 2020 This is very interesting stuff! Thanks a lot.
• jmh530 (3/10) Apr 20 2020 Definitely interesting stuff. Glad to see that the infrastructure
• Jean-Louis Leroy (21/25) Apr 20 2020 The blog post is still current. I remember that, in 2017, some
• jmh530 (4/13) Apr 20 2020 I'm skeptical Walter will ever allow something like #2. Probably

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

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

=?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

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.

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'.

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).