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
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 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 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 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 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 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 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 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 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 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 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 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 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
openmethods is now available in the dub registry:
https://code.dlang.org/packages/openmethods
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
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, 30 August 2017 at 15:42:09 UTC, jmh530 wrote:
One thing you didn't really cover is how seamlessly interacts
with normal polymorphism. For instance, what if to your first
example, I add the following function (note: without @method)
and adjust main as below. I see no reason why
On Wednesday, 30 August 2017 at 16:45:19 UTC, data pulverizer
wrote:
One thing that confused me was examples like this ...
@method
Matrix _plus(DiagonalMatrix a, DiagonalMatrix b)
{
// just add the elements on diagonals
// return a DiagonalMatrix
}
Which is marked as returning a
On Wednesday, 30 August 2017 at 16:37:20 UTC, Q. Schroll wrote:
In the article it says:
Finally, main calls updateMethods. This should be done before
calling any method (typically first thing in main) and each
time a library containing methods is dynamically loaded or
unloaded.
If the
On Wednesday, 30 August 2017 at 17:16:59 UTC, data pulverizer
wrote:
p.p.s
typeof(x[1]) # returns Cat
so it isn't really polymorphism - the object is never converted
to the "parent" type! Lol ... sorry for the confusion!
Which is polymorphism
Haha what I know of Julia is what wikipedia
On Wednesday, 30 August 2017 at 18:20:46 UTC, Jean-Louis Leroy
wrote:
On Wednesday, 30 August 2017 at 18:05:38 UTC, jmh530 wrote:
On Wednesday, 30 August 2017 at 17:24:55 UTC, Jean-Louis Leroy
wrote:
We had a discussion about automating the call to
updateMethods but I don't think that
On Wednesday, 30 August 2017 at 18:16:47 UTC, jmh530 wrote:
I tried installing the latest release from github. Compiling
(Windows 7 on DMD with default options) the simple program below
import openmethods;
mixin(registerMethods);
void main()
{
}
gives me the errors:
Gosh Windows I
On Wednesday, 30 August 2017 at 18:05:38 UTC, jmh530 wrote:
On Wednesday, 30 August 2017 at 17:24:55 UTC, Jean-Louis Leroy
wrote:
We had a discussion about automating the call to updateMethods
but I don't think that anybody thought of putting it in
registerMethods. It might work. I'll look
On Wednesday, 30 August 2017 at 22:30:12 UTC, data pulverizer
wrote:
On Wednesday, 30 August 2017 at 22:10:38 UTC, Jean-Louis Leroy
wrote:
On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer
wrote:
In the light of this I think your package just became more
interesting to me.
I
On Wednesday, 30 August 2017 at 17:16:59 UTC, data pulverizer
wrote:
On Wednesday, 30 August 2017 at 17:14:37 UTC, data pulverizer
wrote:
On Wednesday, 30 August 2017 at 16:45:19 UTC, data pulverizer
wrote:
You mentioned Julia in your article, however for clarity I
would point out that Julia
On Wednesday, 30 August 2017 at 21:30:29 UTC, data pulverizer
wrote:
In the light of this I think your package just became more
interesting to me.
I think that your work and mine are complementary :-)
On Thursday, 24 August 2017 at 23:50:21 UTC, data pulverizer
wrote:
I find OOP-polymorphic types ultimately unsatisfying, but I
don't know of anyway to write, compile and load a D script with
new types and methods on the fly into the same session.
That is why binding membership and
On Thursday, 24 August 2017 at 23:50:21 UTC, data pulverizer
wrote:
I find OOP-polymorphic types ultimately unsatisfying, but I
don't know of anyway to write, compile and load a D script with
new types and methods on the fly into the same session.
That is why binding membership and
On Monday, 28 August 2017 at 12:31:20 UTC, rikki cattermole wrote:
On 28/08/2017 1:19 PM, Mike Parker wrote:
Jean-Louis Leroy posted about his open methods library here in
the forums some time ago. Now, he's written a blog post that
explains what open methods are, and describes the D
On Thursday, 31 August 2017 at 11:39:30 UTC, aberba wrote:
Thanks for this library. Just a suggestion. Would it possible
to use `@openmethod` instead of `@method`?
alias openmethod = method;
Atila
What happens when there is UDA name collision? if its
catastrophic, then @openmethods makes
On Thursday, 31 August 2017 at 21:42:50 UTC, EntangledQuanta
wrote:
It's fixed now, in master and in release v1.0.0-rc.2.
I'll check it out. I don't think the last errors I was getting
were due to the sizing issues though, so is that all you fixed
or was there some other stuff related to
On Thursday, 31 August 2017 at 06:58:53 UTC, Petar Kirov
[ZombineDev] wrote:
The workaround is to cast to Object before getting the typeid.
The cause for this behavior is that if you have an interface
reference to an object it points to the interface vtbl and not
to the Object base class vtbl.
On Thursday, 31 August 2017 at 23:37:03 UTC, EntangledQuanta
wrote:
[Windows]
I'll try again at some point. I haven't got around to messing
with it again.
Did you get a chance?
On Saturday, 2 September 2017 at 20:55:13 UTC, EntangledQuanta
wrote:
This is when I have the mixin(registerMethods) in a module that
doesn't use any open methods. It says add once per module in
the help, but I think it means once per module where open
methods are used?
Yes I meant that.
On Wednesday, 30 August 2017 at 04:48:11 UTC, Arun Chandrasekaran
wrote:
On Tuesday, 29 August 2017 at 12:45:50 UTC, Jean-Louis Leroy
wrote:
On Tuesday, 29 August 2017 at 12:09:01 UTC, Mark wrote:
Nice. This does seem superior to the visitor pattern.
Here is another example - AST traversal:
On Tuesday, 29 August 2017 at 12:09:01 UTC, Mark wrote:
Nice. This does seem superior to the visitor pattern.
Here is another example - AST traversal:
https://github.com/jll63/openmethods.d/blob/master/examples/acceptnovisitors/source/app.d
On Wednesday, 30 August 2017 at 14:37:14 UTC, Arun Chandrasekaran
wrote:
On Wednesday, 30 August 2017 at 13:35:22 UTC, Jean-Louis Leroy
wrote:
On Wednesday, 30 August 2017 at 04:48:11 UTC, Arun What was
your rationale for `openmethod` instead of just `method`?
Just that `openmethod` precisely
On Wednesday, 30 August 2017 at 15:14:04 UTC, rikki cattermole
wrote:
On 30/08/2017 4:10 PM, Jean-Louis Leroy wrote:
On Wednesday, 30 August 2017 at 14:37:14 UTC, Arun
Chandrasekaran wrote:
[...]
I sort of agree, and somewhat regret not picking 'openmethod'.
I considered both. Also
On Thursday, 31 August 2017 at 14:52:43 UTC, jmh530 wrote:
On Wednesday, 30 August 2017 at 15:59:32 UTC, Jean-Louis Leroy
wrote:
What happens here is that kick(Animal) is shadowed by
kick(Dog). kick(Animal) is a method but it appears to the user
and the compiler as an ordinary function -
On Wednesday, 30 August 2017 at 18:16:47 UTC, jmh530 wrote:
..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(970,21): Error: ca
nnot implicitly convert expression h of type ulong to uint
..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(1076,34): Error: c
annot
On Thursday, 31 August 2017 at 20:42:36 UTC, EntangledQuanta
wrote:
On Wednesday, 30 August 2017 at 18:16:47 UTC, jmh530 wrote:
On Wednesday, 30 August 2017 at 15:59:32 UTC, Jean-Louis Leroy
wrote:
What happens here is that kick(Animal) is shadowed by
kick(Dog). kick(Animal) is a method but it
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
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
On Wednesday, 15 April 2020 at 08:00:12 UTC, bogdan wrote:
I use a similar approach in openmethods. With the added twist
that I need to re-create functions from existing functions, with
some modifications (e.g. change the parameter types, add a
parameter), while preserving function and
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
On Wednesday, 22 April 2020 at 05:20:18 UTC, Stefan Koch wrote:
On Tuesday, 21 April 2020 at 14:43:04 UTC, Jean-Louis Leroy
wrote:
I wonder if templates are lazily expanded. I haven't looked at
the compiler's code, my guess is: maybe not.
If the template gets used it gets instantiated (and
On Wednesday, 22 April 2020 at 17:16:28 UTC, Stefan Koch wrote:
I am working on a much more powerful and efficient meta
programming system.
Great! Is it going to be in a library, or part of the compiler?
Can we get a preview somewhere?
On Wednesday, 22 April 2020 at 17:32:33 UTC, Stefan Koch wrote:
It's going to be part of the compiler.
You can look at the ... expression DIP.
which Manu posted in General, for taste of where my stuff is
going.
I think I see the point - I am familiar with C++ variadic
templates.
Yes,
On Thursday, 17 September 2020 at 13:23:38 UTC, Jean-Louis Leroy
wrote:
Actually, Parameters!origFun will carry storage classes, UDAs,
etc for all the parameters. And Parameters!origFun[0..1] (note
the two dots) will carry everything about the first parameter.
The trouble begins when, for some
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:
DIP 1030, "Named Arguments", has been accepted.
During the assessment, Walter and Atila had a discussion
regarding this particular criticism:
On Thursday, 17 September 2020 at 13:45:16 UTC, Mike Parker wrote:
On Thursday, 17 September 2020 at 13:42:47 UTC, Jean-Louis
Leroy wrote:
this point I have some hope that the DIP is not damaging in
the way Mike thinks.
What Mike thinks appears nowhere in my post :-)
OK, s/thinks/reports/
On Thursday, 17 September 2020 at 12:58:06 UTC, Mike Parker wrote:
So they decided that a new `std.traits` template and a
corresponding `__traits` option are needed which expand into
the exact function signature of another function.
I have been trying to locate that specific discussion,
On Friday, 18 September 2020 at 13:39:14 UTC, Mike Parker wrote:
It's from a phone call they had while they were discussing
whether to approve or reject the DIP.
LOL no wonder I couldn't find it.
56 matches
Mail list logo
