Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 15:56:06 UTC, Jean-Louis Leroy wrote: Among other things, the mixin introduces two functions in the module's scope: the function the user actually calls (the "dispatcher"). E.g. it creates a times(double, Matrix) when it sees a times(double, virtual!Matrix). It also declares a "discriminator" function which is used to locate which method the specializations (the @method funcs) relates to (it has to deal with overloads - there are two "times" methods). This has to be done for every module that contains method declarations (virtual!) or implementations (@method). That's why it has to be a string mixin (at least until we have static foreach) and be called in the matrix etc modules, not in module openmethods. I see what you mean. It only works per thread, not per module. What you really need is some kind of module constructor.
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 15:33:28 UTC, jmh530 wrote: Yes. I haven't tried something like that, but it seems like a use case for either static this or shared static this. https://dlang.org/spec/class.html#StaticConstructor https://dlang.org/spec/class.html#SharedStaticConstructor Based on some of your README.md text, you may need to do static this rather than shared static this for what I suggested. I don't really know, but worth investigating. I liked Ali's suggestion for mixin updateMethods. Again, not sure if it should be static this or shared static this, but if you have static this for registerMethods, then a shared static this for updateMethods may occur before that. I'm not sure how important the order is.
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 15:33:28 UTC, jmh530 wrote:
On Wednesday, 19 July 2017 at 13:46:24 UTC, Jean-Louis Leroy
wrote:
What if you do:
shared static this(){
mixin(registerMethods);
}
You mean in openmethods.d?
Yes. I haven't tried something like that, but it seems like a
use case for either static this or shared static this.
https://dlang.org/spec/class.html#StaticConstructor
https://dlang.org/spec/class.html#SharedStaticConstructor
Among other things, the mixin introduces two functions in the
module's scope: the function the user actually calls (the
"dispatcher"). E.g. it creates a times(double, Matrix) when it
sees a times(double, virtual!Matrix). It also declares a
"discriminator" function which is used to locate which method the
specializations (the @method funcs) relates to (it has to deal
with overloads - there are two "times" methods). This has to be
done for every module that contains method declarations
(virtual!) or implementations (@method). That's why it has to be
a string mixin (at least until we have static foreach) and be
called in the matrix etc modules, not in module openmethods.
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 13:46:24 UTC, Jean-Louis Leroy
wrote:
What if you do:
shared static this(){
mixin(registerMethods);
}
You mean in openmethods.d?
Yes. I haven't tried something like that, but it seems like a use
case for either static this or shared static this.
https://dlang.org/spec/class.html#StaticConstructor
https://dlang.org/spec/class.html#SharedStaticConstructor
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 13:36:55 UTC, jmh530 wrote:
On Wednesday, 19 July 2017 at 13:35:40 UTC, jmh530 wrote:
On Wednesday, 19 July 2017 at 12:29:36 UTC, Jean-Louis Leroy
wrote:
...that does the two above. Problem is, it needs -Jpath on
the command line to work. Unless there is a workaround?
I prefer the original.
What if you do:
shared static this(){
mixin(registerMethods);
}
You mean in openmethods.d?
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 13:35:40 UTC, jmh530 wrote:
On Wednesday, 19 July 2017 at 12:29:36 UTC, Jean-Louis Leroy
wrote:
...that does the two above. Problem is, it needs -Jpath on the
command line to work. Unless there is a workaround?
I prefer the original.
What if you do:
shared static this(){
mixin(registerMethods);
}
Re: New library: open multi-methods
On Wednesday, 19 July 2017 at 12:29:36 UTC, Jean-Louis Leroy wrote: ...that does the two above. Problem is, it needs -Jpath on the command line to work. Unless there is a workaround? I prefer the original.
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 18:21:21 UTC, Ali Çehreli wrote:
On 07/18/2017 11:03 AM, jmh530 wrote:
> the mixin(registerMethods); could then be adjusted so that
void
> print(virtual!Matrix m); is mixed in automatically because we
now know
> how to construct it.
That reminds me: Would the following be possible and better?
// From
void main()
{
updateMethods();
// ...
}
// To
mixin(constructMethods());
void main()
{
// ...
}
constructMethods() could return the following string:
string constructMethods() {
return q{
shared static this() { updateMethods(); }
};
}
OK, I think I may have found solutions to both problems. The
question is, is it too hacky?
1/ method registration
Replace this:
import openmethods;
mixin(registerMethods);
...with:
mixin(import(openmethoddecls));
...that does the two above. Problem is, it needs -Jpath on the
command line to work. Unless there is a workaround?
2/ updateMethods
During static construction, I could set the dispatch tables to
make all the methods call a function that does updateMethods()
then re-dispatches. The cost of the first method call would be
huge, but if it matters the user can still call updateMethods
explicitly.
Thoughts?
Re: New library: open multi-methods
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.
Re: New library: open multi-methods
openmethods is now available in the dub registry: https://code.dlang.org/packages/openmethods
Re: New library: open multi-methods
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.
Re: New library: open multi-methods
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.
Re: New library: open multi-methods
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.
Re: New library: open multi-methods
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
Re: New library: open multi-methods
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.
Re: New library: open multi-methods
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.
Re: New library: open multi-methods
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.
Re: New library: open multi-methods
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
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 18:03:30 UTC, jmh530 wrote:
On Tuesday, 18 July 2017 at 16:57:30 UTC, Ali Çehreli wrote:
Perhaps they are all needed but I'm thinking about the need
for forward declaration, the need for the underscore prefix,
etc.
He might be able to at least get rid of the forward declaration
(not sure on the underscore).
The way it works now is that a class that inherits from an
interface is not required in any way to implement the methods.
Suppose he adds another attribute to an interface such that any
class that inherits from it is required to have methods defined
for specific functions.
So for instance, the Matrix example might look something like
@trait
interface Matrix
{
@property int rows() const;
@property int cols() const;
@property double at(int i, int j) const;
@trait void print();
}
I'm not sure this would work because anything that derives from
Matrix must implement print. However, if it is possible to use
the attribute to allow the derived classes to ignore print,
then it might work. Alternately, if there is a way to process
the interface and tell the compiler to somehow ignore the
@trait member functions. I don't know if it'll work, but it's
an idea.
Anyway, the mixin(registerMethods); could then be adjusted so
that void print(virtual!Matrix m); is mixed in automatically
because we now know how to construct it.
There are at least problems with this. Firstly it is intrusive -
something I strive to avoid (although I could be 100% orthogonal
only because I hijack a deprecated pointer in ClassInfo). Also,
some methods may want to treat Matrix as a virtual argument, and
some not.
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
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 18:21:21 UTC, Ali Çehreli wrote:
That reminds me: Would the following be possible and better?
// From
void main()
{
updateMethods();
// ...
}
// To
mixin(constructMethods());
void main()
{
// ...
}
constructMethods() could return the following string:
string constructMethods() {
return q{
shared static this() { updateMethods(); }
};
}
If I'm not missing something, this is better because nothing
needs to be added to main and the methods are available before
main starts executing (module initialization order issues still
apply.).
Ah, I would love to get rid of that call in main(), but think
beyond a one module program. The matrix example
(https://github.com/jll63/methods.d/tree/master/examples/matrix/source) consists in three separate modules, plus an app, all defining specializations. They need the mixin, but if we put updateMehods() in there, it will be called many times. And it is a costly operation. Guarding the call with a flag will not work, because more methods may be registered afterwards. Unless you can think of a way the last mixin can detect it's the last?
Incidentally, in yomm11 that function (it's called initialize())
has to be called before any method is called, after any shared
object/DLL is loaded and after a DLL is unloaded. I still have to
write the code to de-register the methods and the specializations
in that case by the way...
J-L
J-L
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 16:57:30 UTC, Ali Çehreli wrote:
> As for performance, I have a first result:
>
https://github.com/jll63/methods.d/blob/master/benchmarks/source/benchmarks.d#L122
> but I still have to implement the "first argument
optimization". I am
> working on it.
I could use some explanation for the results but I can for the
blog article. ;)
I pit a method-based call against its equivalent using virtual
functions. First calling a virtual function via a base class is
pitted against a method with one virtual parameter. Then the same
but calling via an interface. Lastly, I compare double dispatch
with a method with two virtual arguments. I use
std.datetime.comparingBenchmark, which reports the result as
time(base)/time(target). So open methods are a bit slower than
ordinary virtual function calls but not that much. In the
meantime I have applied a second optimization for unary methods
and this brings them within 33% of an ordinary, compiler
implemented vfunc call. Which is OK because the situation is
highly artificial. If the function does anything, the difference
will be imperceptible.
I am more annoyed by double dispatch beating binary methods. I
will have to look at the assembler, but it may be that the index
pointer is too far from the object. To begin the real work, I
need to fetch that pointer form an object. Currently it is stored
in ClassInfo.deallocator, so I have to 1/ fetch the vptr 2/ fetch
the ClassInfo* 3/ fetch 'deallocator'. What happens next depends
on the arity.
Any chance of Walter giving me a pointer in the vtable? Aside the
ClassInfo*? Or at least a pointer in ClassInfo, or reassign the
deallocator when it is eventually retired?
It's not surprising that ldc (and gdc) can be much better than
dmd in optimization.
I would like to try gdc but it conflicts with ldc2 - you know,
the "alias __va_list = __va_list_tag;" issue. I found suggestions
via google but nothing worked for me so far.
By the way, I'm in awe of your D skills in such a short time!
Thanks :) I found out that D was much more natural, "predictable"
than C++. The most cryptic error messages happened when I forgot
the "!", IIRC.
I'm sure there are parts of the code that can be cleaned up but
it's taking advantage of many powerful features of the
language. I still think the usage can be made easier but I'm
not sure yet. I hope others will take a look at the code and
come up with an easier interface. Perhaps they are all needed
but I'm thinking about the need for forward declaration, the
need for the underscore prefix, etc.
(in reverse order)
Regarding the prefix, it is needed to prevent overload resolution
from trumping dynamic dispatch - see here:
https://github.com/jll63/methods.d/blob/master/examples/whytheunderscore/source/app.d Allowing the same name would necessitate compiler support.
As for the the forward declaration - I don't think it is possible
to dispense with it. All open methods systems I know of have it
(defgeneric in CLOS, defmulti in Clojure, Stroustrup's
proposal...). Consider:
class A { }
class B : A { }
class X : B { }
class Y : B { }
@method void _foo(virtual!X x) { ... }
@method void _foo(virtual!Y x) { ... }
What is the base method? foo(B)? foo(A)? It may well be the
latter. Also don't forget that the complete specialization set is
known, at the earliest, at link time. If you (arbitrarily) pick
foo(B), another module may introduce a B or an A specialization.
As for suggestions and advise, they are very welcome :) already
got a couple of PRs. Here are the remaining questions on my mind:
- the module/package name: I am pretty much set on openmethods
though...
- throw an exception if a method is not define for the argument
set, or ambiguous: having big doubts about this. We want the
possibility of @nothrow methods, don't we? So I will probably
call a delegate via a pointer (a la C++) which, by default, will
abort().
- the method prefix: hesitating between just _ or maybe m_ ???
- replace version(explain) with debug levels?
Re: New library: open multi-methods
On 07/18/2017 11:03 AM, jmh530 wrote:
> the mixin(registerMethods); could then be adjusted so that void
> print(virtual!Matrix m); is mixed in automatically because we now know
> how to construct it.
That reminds me: Would the following be possible and better?
// From
void main()
{
updateMethods();
// ...
}
// To
mixin(constructMethods());
void main()
{
// ...
}
constructMethods() could return the following string:
string constructMethods() {
return q{
shared static this() { updateMethods(); }
};
}
If I'm not missing something, this is better because nothing needs to be
added to main and the methods are available before main starts executing
(module initialization order issues still apply.).
Ali
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 16:57:30 UTC, Ali Çehreli wrote:
Perhaps they are all needed but I'm thinking about the need for
forward declaration, the need for the underscore prefix, etc.
He might be able to at least get rid of the forward declaration
(not sure on the underscore).
The way it works now is that a class that inherits from an
interface is not required in any way to implement the methods.
Suppose he adds another attribute to an interface such that any
class that inherits from it is required to have methods defined
for specific functions.
So for instance, the Matrix example might look something like
@trait
interface Matrix
{
@property int rows() const;
@property int cols() const;
@property double at(int i, int j) const;
@trait void print();
}
I'm not sure this would work because anything that derives from
Matrix must implement print. However, if it is possible to use
the attribute to allow the derived classes to ignore print, then
it might work. Alternately, if there is a way to process the
interface and tell the compiler to somehow ignore the @trait
member functions. I don't know if it'll work, but it's an idea.
Anyway, the mixin(registerMethods); could then be adjusted so
that void print(virtual!Matrix m); is mixed in automatically
because we now know how to construct it.
Re: New library: open multi-methods
On 07/18/2017 12:06 AM, Jean-Louis Leroy wrote: > Yes I will probably write something. You mean on the D Blog? Not necessarily but why not. :) > As for performance, I have a first result: > https://github.com/jll63/methods.d/blob/master/benchmarks/source/benchmarks.d#L122 > but I still have to implement the "first argument optimization". I am > working on it. I could use some explanation for the results but I can for the blog article. ;) It's not surprising that ldc (and gdc) can be much better than dmd in optimization. By the way, I'm in awe of your D skills in such a short time! I'm sure there are parts of the code that can be cleaned up but it's taking advantage of many powerful features of the language. I still think the usage can be made easier but I'm not sure yet. I hope others will take a look at the code and come up with an easier interface. Perhaps they are all needed but I'm thinking about the need for forward declaration, the need for the underscore prefix, etc. Ali
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 07:06:10 UTC, Jean-Louis Leroy wrote: As for performance, I have a first result: https://github.com/jll63/methods.d/blob/master/benchmarks/source/benchmarks.d#L122 but I still have to implement the "first argument optimization". I am working on it. Now this is funny, after implementing that optimization (https://github.com/jll63/methods.d/blob/94ad5a945b3c719bd8f8402bb0aa6fda8e7a6be0/source/openmethods.d#L388, https://github.com/jll63/methods.d/blob/94ad5a945b3c719bd8f8402bb0aa6fda8e7a6be0/benchmarks/source/benchmarks.d#L139) it runs faster with ldc2 but slower with dmd. I may be testing the limits of dmd's willingness to inline my mess ;-) J-L
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 04:26:42 UTC, Ali Çehreli wrote: On 07/16/2017 10:24 AM, Jean-Louis Leroy wrote: > TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md Woot! :) I'm so happy to see this project complete. Honestly, growing up with languages without this feature (C and C++), I've not even known that I needed this feature but your example (e.g. matrix multiplication) are very convincing. Thanks :) I added another example that shows how open methods are a superior alternative to Visitor: https://github.com/jll63/methods.d/blob/master/examples/novisitor/source/app.d If there are enough differences compared to your C++ articles, perhaps you may consider following this up with a blog post. It would be nice to see some performance results as well like you have on your C++ articles. Yes I will probably write something. You mean on the D Blog? As for performance, I have a first result: https://github.com/jll63/methods.d/blob/master/benchmarks/source/benchmarks.d#L122 but I still have to implement the "first argument optimization". I am working on it. J-L Ali
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 02:22:15 UTC, Jay Norwood wrote:
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')
For example, CLOS allows you to specialize on a value (google for
"eql specialize"). IIRC Clojure allows you to specify your own
dispatcher.
As for specializing on D attributes, I don't think it's feasible.
They are a purely compile-time mechanism. In your example, the
type of "s" is "string", not "@('c') string".
J-L
Re: New library: open multi-methods
On 07/16/2017 10:24 AM, Jean-Louis Leroy wrote: > TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md Woot! :) I'm so happy to see this project complete. Honestly, growing up with languages without this feature (C and C++), I've not even known that I needed this feature but your example (e.g. matrix multiplication) are very convincing. If there are enough differences compared to your C++ articles, perhaps you may consider following this up with a blog post. It would be nice to see some performance results as well like you have on your C++ articles. Ali
Re: New library: open multi-methods
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')
Re: New library: open multi-methods
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
Re: New library: open multi-methods
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
Re: New library: open multi-methods
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.
Re: New library: open multi-methods
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
Re: New library: open multi-methods
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.
Re: New library: open multi-methods
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`.
Re: New library: open multi-methods
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.
Re: New library: open multi-methods
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.
New library: open multi-methods
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
