July 18, 2017
On 07/18/2017 12:22 PM, Jean-Louis Leroy wrote:

> Look at
> https://github.com/jll63/methods.d/blob/master/examples/matrix/source/matrix.d
> and
> https://github.com/jll63/methods.d/blob/master/examples/matrix/source/densematrix.d
> They know nothing about printing. They don't want to. The matrix modules
> do math, the app does printing.

Related, our friend Luís Marques was the speaker in January 2016 here at the DLang Silicon Valley meetup. "A defense of so-called anemic domain models":

  https://www.meetup.com/D-Lang-Silicon-Valley/events/228027468/

I'm totally sold on the idea.

Ali

July 18, 2017
On Tuesday, 18 July 2017 at 19:22:38 UTC, Jean-Louis Leroy wrote:
>
> Look at https://github.com/jll63/methods.d/blob/master/examples/matrix/source/matrix.d and https://github.com/jll63/methods.d/blob/master/examples/matrix/source/densematrix.d They know nothing about printing. They don't want to. The matrix modules do math, the app does printing.
>
> J-L

I may not have been clear enough. My ideal solution wouldn't make any changes to that densematrix.d file, just the interface. So I don't have any issue with the matrix modules doing the math and the app doing the printing.

For instance, consider the traits in Rust
https://doc.rust-lang.org/book/first-edition/traits.html
My idea is like making the interfaces in D similar to the traits in Rust (or at least having the option to do something similar with them). Your @method void _print(Matrix m) would be similar to impl print for Matrix in Rust.

Nevertheless, I get that it may be a difficult thing to implement.
July 18, 2017
On Tuesday, 18 July 2017 at 21:16:11 UTC, jmh530 wrote:
>
> I may not have been clear enough. My ideal solution wouldn't make any changes to that densematrix.d file, just the interface. So I don't have any issue with the matrix modules doing the math and the app doing the printing.
>

Well, I suppose the matrix interface would be saying that it can print, so maybe not as split up as you would like. While you could define a separate interface for printing, that would require a change to densematrix.
July 18, 2017
On Tuesday, 18 July 2017 at 21:20:04 UTC, jmh530 wrote:
> On Tuesday, 18 July 2017 at 21:16:11 UTC, jmh530 wrote:
>>
>> I may not have been clear enough. My ideal solution wouldn't make any changes to that densematrix.d file, just the interface. So I don't have any issue with the matrix modules doing the math and the app doing the printing.
>>
>
> Well, I suppose the matrix interface would be saying that it can print, so maybe not as split up as you would like. While you could define a separate interface for printing, that would require a change to densematrix.

Exactly. Orthogonality is essential for good composition, that is the reason why OOP - well, the OOP that follows the Simula/Smalltalk tradition - failed so badly. CLOS got it right 40 years ago; Simula, Smalltalk, C++, Java, etc they all got it wrong.
July 18, 2017
On 07/16/2017 10:24 AM, Jean-Louis Leroy wrote:
> Hello,
>
> TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md

Added D to the Wikipedia entry, which can be expanded. :)

  https://en.wikipedia.org/wiki/Multiple_dispatch

Ali

July 18, 2017
On Tuesday, 18 July 2017 at 22:41:13 UTC, Ali Çehreli wrote:
> On 07/16/2017 10:24 AM, Jean-Louis Leroy wrote:
>> Hello,
>>
>> TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md
>
> Added D to the Wikipedia entry, which can be expanded. :)
>
>   https://en.wikipedia.org/wiki/Multiple_dispatch
>
> Ali

Haha that settles it then, openmethods it is! I'll rename the repo and upload to the registry momentarily.
July 19, 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

Interesting. One problem I think the above approach has is adding methods after compilation. Say, a plugin adds a new derived matrix type SparseMatrix and wants to customize the addition of them. This is impossible under the current model, is it not?

Would it not be possible create a sort of "externmultimethod" that mimics extern'ing a method? Basically, on the "server/host" side there is a method that can be used to add new multimethods at runtime. It takes meta data and extends the virtual table to handle dispatching it along with the other functions. The "client/plugin" side has the multimethod it wants to add to the dispatch and it does this by giving it all the needed information to do so and using the new externmultimethod method to do it.



July 19, 2017
On Wednesday, 19 July 2017 at 06:27:40 UTC, James Dean wrote:
> Interesting. One problem I think the above approach has is adding methods after compilation. Say, a plugin adds a new derived matrix type SparseMatrix and wants to customize the addition of them. This is impossible under the current model, is it not?

Why? I haven't tried it yet (putting together an example is one of the TODOs before v1.0.0) but I fully expect it to work. The dispatch tables are created at compile time. Just call updateMethods after loading or unloading the DLL and it should work. It does in the C++ version.
July 19, 2017
openmethods is now available in the dub registry: https://code.dlang.org/packages/openmethods

July 19, 2017
On Tuesday, 18 July 2017 at 04:26:42 UTC, Ali Çehreli wrote:
> It would be nice to see some performance results as well like you have on your C++ articles.

Lib is in the dub registry now. Do you have a working gdc compiler? If yes, could you run the benchmark and post the results? Please make sure to build in release mode.