Jump to page: 1 24  
Page
Thread overview
New library: open multi-methods
Jul 16, 2017
Jean-Louis Leroy
Jul 16, 2017
Eugene Wissner
Jul 17, 2017
Jean-Louis Leroy
Jul 17, 2017
jmh530
Jul 17, 2017
jmh530
Jul 18, 2017
Jean-Louis Leroy
Jul 17, 2017
Jean-Louis Leroy
Jul 17, 2017
jmh530
Jul 18, 2017
Jean-Louis Leroy
Jul 18, 2017
Jay Norwood
Jul 18, 2017
Jean-Louis Leroy
Jul 18, 2017
Ali Çehreli
Jul 18, 2017
Jean-Louis Leroy
Jul 18, 2017
Jean-Louis Leroy
Jul 18, 2017
Ali Çehreli
Jul 18, 2017
jmh530
Jul 18, 2017
Ali Çehreli
Jul 18, 2017
Jean-Louis Leroy
Jul 19, 2017
Jean-Louis Leroy
Jul 19, 2017
jmh530
Jul 19, 2017
jmh530
Jul 19, 2017
Jean-Louis Leroy
Jul 19, 2017
jmh530
Jul 19, 2017
Jean-Louis Leroy
Jul 19, 2017
jmh530
Jul 19, 2017
jmh530
Jul 18, 2017
Jean-Louis Leroy
Jul 18, 2017
Ali Çehreli
Jul 18, 2017
jmh530
Jul 18, 2017
jmh530
Jul 18, 2017
Jean-Louis Leroy
Jul 18, 2017
Jean-Louis Leroy
Jul 19, 2017
Jean-Louis Leroy
Jul 18, 2017
Ali Çehreli
Jul 18, 2017
Jean-Louis Leroy
Jul 19, 2017
James Dean
Jul 19, 2017
Jean-Louis Leroy
Jul 19, 2017
Jean-Louis Leroy
July 16, 2017
Hello,

TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md for an explanation of what open multi-methods are, if you are not familiar with the idea.You may also want to read my article on Code Project https://www.codeproject.com/Articles/635264/Open-Multi-Methods-for-Cplusplus11-Part-1

Earlier this year I attended Ali Çehreli's talk at C++ Now. He did a good job: I walked out with the desire to learn about D and see how it measures up against C++, especially in terms of meta-programming and language extensibility. The first programming language I learned is Forth and I did some Lisp programming, so as you can imagine, my expectations are high.

As an experiment, I decided to try to port parts of my yomm11 library to D. The experience turned out to be pleasant and I ended up writing a full implementation, with some friendly help from Ali and others in the Learn forum.

I think that what I have now is good enough to show. The git repo is here https://github.com/jll63/methods.d and I will post a package to the registry soon.

If you have the inclination, feel free to review and comment. This is my very first D project and I certainly have missed some idioms and been clumsy at times.

Jean-Louis Leroy

July 16, 2017
On Sunday, 16 July 2017 at 17:24:17 UTC, Jean-Louis Leroy wrote:
> Hello,
>
> TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md for an explanation of what open multi-methods are, if you are not familiar with the idea.You may also want to read my article on Code Project https://www.codeproject.com/Articles/635264/Open-Multi-Methods-for-Cplusplus11-Part-1
>
> Earlier this year I attended Ali Çehreli's talk at C++ Now. He did a good job: I walked out with the desire to learn about D and see how it measures up against C++, especially in terms of meta-programming and language extensibility. The first programming language I learned is Forth and I did some Lisp programming, so as you can imagine, my expectations are high.
>
> As an experiment, I decided to try to port parts of my yomm11 library to D. The experience turned out to be pleasant and I ended up writing a full implementation, with some friendly help from Ali and others in the Learn forum.
>
> I think that what I have now is good enough to show. The git repo is here https://github.com/jll63/methods.d and I will post a package to the registry soon.
>
> If you have the inclination, feel free to review and comment. This is my very first D project and I certainly have missed some idioms and been clumsy at times.
>
> Jean-Louis Leroy

You may want to use ```d in your code samples in the README to highlight it.
July 17, 2017
Thinking about it, 'openmethods' would probably be a better module/package name than just 'methods'. It emphasizes the #1 feature, i.e. polymorphism outside of classes.
July 17, 2017
On Monday, 17 July 2017 at 20:41:05 UTC, Jean-Louis Leroy wrote:
> Thinking about it, 'openmethods' would probably be a better module/package name than just 'methods'. It emphasizes the #1 feature, i.e. polymorphism outside of classes.

Googling `multimethods` brought up more programming-related topics than `openmethods`.
July 17, 2017
On Monday, 17 July 2017 at 21:31:20 UTC, jmh530 wrote:
> On Monday, 17 July 2017 at 20:41:05 UTC, Jean-Louis Leroy wrote:
>> Thinking about it, 'openmethods' would probably be a better module/package name than just 'methods'. It emphasizes the #1 feature, i.e. polymorphism outside of classes.
>
> Googling `multimethods` brought up more programming-related topics than `openmethods`.

Or you could call it omm and then just refer to open multi-methods in the documentation.
July 17, 2017
On Monday, 17 July 2017 at 21:31:20 UTC, jmh530 wrote:
> On Monday, 17 July 2017 at 20:41:05 UTC, Jean-Louis Leroy wrote:
>> Thinking about it, 'openmethods' would probably be a better module/package name than just 'methods'. It emphasizes the #1 feature, i.e. polymorphism outside of classes.
>
> Googling `multimethods` brought up more programming-related topics than `openmethods`.

Yeah, I know, but I can imagine someone casually browsing the registry, coming across the module and saying "multi-methods? yeah, cool, but I don't remember ever needing such a thing". Indeed "multi" is nice, but IMO "open" is much more important. It is still much more frequent to have only one virtual argument. Take the awful Visitor pattern, for example. It can be neatly replaced with an open method taking only one virtual argument (barring other considerations).

'openmultimethods' is another option but again it emphasizes 'multi'.

Anyway, if I go for just 'openmethods', there are enough mentions of 'multi-methods' in the docs.

I think I will rename 'methods' to 'openmethods' for the time being, but the discussion remains open. Not renaming the repo yet.

Thinking about it, I should add a Visitor replacement example...

J-L
July 17, 2017
On Monday, 17 July 2017 at 22:46:02 UTC, Jean-Louis Leroy wrote:
>
> I think I will rename 'methods' to 'openmethods' for the time being, but the discussion remains open. Not renaming the repo yet.


On the other hand, when I saw methods, my first thought was R's methods, which I imagine is similar if I'm not mistaken.
July 18, 2017
On Monday, 17 July 2017 at 22:59:03 UTC, jmh530 wrote:
> On Monday, 17 July 2017 at 22:46:02 UTC, Jean-Louis Leroy wrote:
>>
>> I think I will rename 'methods' to 'openmethods' for the time being, but the discussion remains open. Not renaming the repo yet.
>
>
> On the other hand, when I saw methods, my first thought was R's methods, which I imagine is similar if I'm not mistaken.

I don't know R but after a trip to Wikipedia it looks like it.

J-L
July 18, 2017
On Monday, 17 July 2017 at 21:32:13 UTC, jmh530 wrote:
> On Monday, 17 July 2017 at 21:31:20 UTC, jmh530 wrote:
>> On Monday, 17 July 2017 at 20:41:05 UTC, Jean-Louis Leroy wrote:
>>> Thinking about it, 'openmethods' would probably be a better module/package name than just 'methods'. It emphasizes the #1 feature, i.e. polymorphism outside of classes.
>>
>> Googling `multimethods` brought up more programming-related topics than `openmethods`.
>
> Or you could call it omm and then just refer to open multi-methods in the documentation.

Yeah that's what the omm in yomm11 means, but I am not too fond of acronyms. In C++ it was the library name (-lyomm11) and also the project name but no the namespace.

J-L

July 18, 2017
On Tuesday, 18 July 2017 at 00:47:04 UTC, Jean-Louis Leroy wrote:
> I don't know R but after a trip to Wikipedia it looks like it.
>
> J-L

R is listed as one of the languages with built-in support in this wiki link.  I searched for  multiple dispatch because I was familiar with the similar feature in julia, and that's how they refer to it.
https://en.wikipedia.org/wiki/Multiple_dispatch

An excerpt statement from this wiki page is :
"  dynamically dispatched based on the run-time (dynamic) type or, in the more general case some other attribute, of more than one of its arguments"


Based on the 'some other attribute', I wonder if the library could conceivably be extended to dispatch based on the User Defined Attribute info

https://dlang.org/spec/attribute.html

@('c') string s;
pragma(msg, __traits(getAttributes, s)); // prints tuple('c')




« First   ‹ Prev
1 2 3 4