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
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 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
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.
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
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
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.
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
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
openmethods is now available in the dub registry:
https://code.dlang.org/packages/openmethods
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
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
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. :)
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
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
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
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.
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
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
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
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
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()
{
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
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
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
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
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
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
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
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
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,
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
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.
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.
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
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.
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
37 matches
Mail list logo
