www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Open Methods: From C++ to D

reply Mike Parker <aldacron gmail.com> writes:
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 
implementation and how it compares to his C++ library.

The blog:
https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/

Reddit:
https://www.reddit.com/r/programming/comments/6wj0ev/open_methods_from_c_to_d/
Aug 28 2017
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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 implementation and how it compares 
 to his C++ library.
 
 The blog:
 https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/
 
 Reddit:
 https://www.reddit.com/r/programming/comments/6wj0ev/open_methods_from_c_to_d/ 
Neat. Good to see articles in support of TypeInfo/ClassInfo! I do wish we extended it for full reflection capabilities though...
Aug 28 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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 
 implementation and how it compares to his C++ library.
 
 The blog:
 https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/
 
 Reddit:
 https://www.reddit.com/r/programming/comments/6wj0ev/open_methods_from_c_to_d/
Neat. Good to see articles in support of TypeInfo/ClassInfo! I do wish we extended it for full reflection capabilities though...
Agreed. Andrei suggested using rtlInfo but AFAICT this requires building a custom druntime. It would be easy to support this method in addition to 'deallocator' and 'hash' but I suspect it would not be a very popular option. Maybe we could have a void*[] in TypeInfo and a global integer index that extensions could use to allocate entries?
Aug 28 2017
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 28/08/2017 9:06 PM, Jean-Louis Leroy wrote:
 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 implementation and how it 
 compares to his C++ library.

 The blog:
 https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/

 Reddit:
 https://www.reddit.com/r/programming/comments/6wj0ev/open_methods_from_c_to_d/ 
Neat. Good to see articles in support of TypeInfo/ClassInfo! I do wish we extended it for full reflection capabilities though...
Agreed. Andrei suggested using rtlInfo but AFAICT this requires building a custom druntime. It would be easy to support this method in addition to 'deallocator' and 'hash' but I suspect it would not be a very popular option. Maybe we could have a void*[] in TypeInfo and a global integer index that extensions could use to allocate entries?
Instead of hacking new features in, we should work on a full redesign. Clearly its needed between TypeInfo not cross the dll boundary on Windows (yay no classes!), -betterC and of course full reflection that we can do significantly better in this department.
Aug 28 2017
prev sibling next sibling parent reply Mark <smarksc gmail.com> writes:
On Monday, 28 August 2017 at 12:19:26 UTC, 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 
 implementation and how it compares to his C++ library.

 The blog:
 https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/

 Reddit:
 https://www.reddit.com/r/programming/comments/6wj0ev/open_methods_from_c_to_d/
Nice. This does seem superior to the visitor pattern.
Aug 29 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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
Aug 29 2017
parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
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: https://github.com/jll63/openmethods.d/blob/master/examples/acceptnovisitors/source/app.d
Thanks for this library. Just a suggestion. Would it possible to use ` openmethod` instead of ` method`?
Aug 29 2017
next sibling parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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: https://github.com/jll63/openmethods.d/blob/master/examples/acceptnovisitors/source/app.d
Thanks for this library. Just a suggestion. Would it possible to use ` openmethod` instead of ` method`?
Ah, I think it's a little late for that. A while ago I asked if anyone had suggestions regarding that sort of things...But now that the article has been published I think it would be a very bad idea to break all the exmaples in it. What was your rationale for `openmethod` instead of just `method`? I will push a commit tonight that will make this work: import openmethods : virtual, openmethod = method, next, registerMethods, updateMethods; // ... openmethod // implement 'kick' for dogs string _kick(Dog x) // note the underscore { return "bark"; }
Aug 30 2017
parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
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 expresses it's intent and `method` is too generic.
Aug 30 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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 expresses it's intent and `method` is too generic.
I sort of agree, and somewhat regret not picking 'openmethod'. I considered both. Also specialize. If anyone had pushed for openmethod before the article, I would almost certainly have given in. My reasoning was, I hope to promote the term 'method' as the standard name for polymorphism from outside, as opposed to vfunc. We usually say "virtual functions", rarely "virtual member functions". Membership is implicit.
Aug 30 2017
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 30/08/2017 4:10 PM, Jean-Louis Leroy wrote:
 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 expresses it's intent and `method` is too generic.
I sort of agree, and somewhat regret not picking 'openmethod'. I considered both. Also specialize. If anyone had pushed for openmethod before the article, I would almost certainly have given in. My reasoning was, I hope to promote the term 'method' as the standard name for polymorphism from outside, as opposed to vfunc. We usually say "virtual functions", rarely "virtual member functions". Membership is implicit.
Rename, alias to old and have it deprecated. Keep around for a couple of releases, done!
Aug 30 2017
parent Jean-Louis Leroy <jl leroy.nyc> writes:
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 specialize. If anyone had pushed for openmethod before the article, I would almost certainly have given in. My reasoning was, I hope to promote the term 'method' as the standard name for polymorphism from outside, as opposed to vfunc. We usually say "virtual functions", rarely "virtual member functions". Membership is implicit.
Rename, alias to old and have it deprecated. Keep around for a couple of releases, done!
Deprecated, already? :-D Hmmm maybe...Let's see if anyone speaks in favor of just method.
Aug 30 2017
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 30 August 2017 at 15:10:03 UTC, Jean-Louis Leroy 
wrote:
 I sort of agree, and somewhat regret not picking 'openmethod'. 
 I considered both. Also  specialize. If anyone had pushed for 
  openmethod before the article, I would almost certainly have 
 given in.

 My reasoning was, I hope to promote the term 'method' as the 
 standard name for polymorphism from outside, as opposed to 
 vfunc. We usually say "virtual functions", rarely "virtual 
 member functions". Membership is implicit.
We had some discussion about what to name it in the original announce thread, but I didn't want to get too focused on bikeshedding the names and you had made good points. method is probably better than specialize. Not sure what additional information you get from openmethod, given that you're already importing from openmethods, but I don't really care that much. 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 this shouldn't work. But you wouldn't be able to create a string kick(Animal animal) function since that is created by the mixin. string kick(Dog dog) { return "ct bark"; } void main() { updateMethods(); import std.stdio : writeln; Animal snoopy = new Dog, hector = new Pitbull; writeln("snoopy.kick(): ", snoopy.kick()); // bark writeln("hector.kick(): ", hector.kick()); // bark an dbite Dog lassie = new Dog; writeln("lassie.kick(): ", lassie.kick()); // ct bark }
Aug 30 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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 this shouldn't 
 work. But you wouldn't be able to create a string kick(Animal 
 animal) function since that is created by the mixin.

 string kick(Dog dog) { return "ct bark"; }

 void main()
 {
   updateMethods();
   import std.stdio : writeln;
   Animal snoopy = new Dog, hector = new Pitbull;
   writeln("snoopy.kick(): ", snoopy.kick()); // bark
   writeln("hector.kick(): ", hector.kick()); // bark an dbite
   Dog lassie = new Dog;
   writeln("lassie.kick(): ", lassie.kick()); // ct bark
 }
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 - which is generally good. As such it is eligible for UFCS. I would not recommend this sort of coding, but it's everyone's choice, methods or not. Likewise, methods can be overloaded (like here https://github.com/jll63/openmethods.d/blob/1.0.0-rc.1/examples/matrix/source/matrix.d#L12). A current limitation is that default arguments are not supported (yet), although I think it's just a matter of putting the effort in. UFCS interacts nicely with methods because you can say a.plus(b) even if 'plus' is an open method.
Aug 30 2017
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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 - which is generally 
 good. As such it is eligible for UFCS. I would not recommend 
 this sort of coding, but it's everyone's choice, methods or not.

 Likewise, methods can be overloaded (like here 
 https://github.com/jll63/openmethods.d/blob/1.0.0-rc.1/examples/matrix/source/matrix.d#L12).

 A current limitation is that default arguments are not 
 supported (yet), although I think it's just a matter of putting 
 the effort in.

 UFCS interacts nicely with methods because you can say 
 a.plus(b) even if 'plus' is an open method.
I can submit this as an issue on the github page, but I figured I'd mention it here in case there was some easy fix. 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: ..\..\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 implicitly convert expression dim of type ulong to uint ..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(1177,23): Error: c annot implicitly convert expression h of type ulong to uint dmd failed with exit code 1. The error at line 1076 can be fixed by changing the type of dim in the function to size_t. I couldn't fix the other errors. I tried having the hash function return size_t also, but that just causes other problems.
Aug 30 2017
next sibling parent Jean-Louis Leroy <jl leroy.nyc> writes:
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 completely forgot about that...I'll take a look tonight.
Aug 30 2017
prev sibling next sibling parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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 implicitly convert expression dim of type ulong to uint
 ..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(1177,23): Error:
c
 annot implicitly convert expression h of type ulong to uint
 dmd failed with exit code 1.

 The error at line 1076 can be fixed by changing the type of dim 
 in the function to size_t. I couldn't fix the other errors. I 
 tried having the hash function return size_t also, but that 
 just causes other problems.
Fixed. Committed to master and it should show up in dub soon. Gosh, all that mind bending meta polymorphic mixin reflection multi-dimensional fu and then fall prey to ints and uints and size_ts. Sobering...
Aug 30 2017
parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 30 August 2017 at 23:40:59 UTC, Jean-Louis Leroy 
wrote:
 Fixed. Committed to master and it should show up in dub soon.

 Gosh, all that mind bending meta polymorphic mixin reflection 
 multi-dimensional fu and then fall prey to ints and uints and 
 size_ts. Sobering...
Ha. Cheers.
Aug 30 2017
prev sibling parent reply EntangledQuanta <EQ universe.com> writes:
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 appears to the user 
 and the compiler as an ordinary function - which is generally 
 good. As such it is eligible for UFCS. I would not recommend 
 this sort of coding, but it's everyone's choice, methods or 
 not.

 Likewise, methods can be overloaded (like here 
 https://github.com/jll63/openmethods.d/blob/1.0.0-rc.1/examples/matrix/source/matrix.d#L12).

 A current limitation is that default arguments are not 
 supported (yet), although I think it's just a matter of 
 putting the effort in.

 UFCS interacts nicely with methods because you can say 
 a.plus(b) even if 'plus' is an open method.
I can submit this as an issue on the github page, but I figured I'd mention it here in case there was some easy fix. 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: ..\..\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 implicitly convert expression dim of type ulong to uint ..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(1177,23): Error: c annot implicitly convert expression h of type ulong to uint dmd failed with exit code 1. The error at line 1076 can be fixed by changing the type of dim in the function to size_t. I couldn't fix the other errors. I tried having the hash function return size_t also, but that just causes other problems.
I was getting similar errors and simply added a cast(size_t)[used in the indexing, as he used ulongs for indexes rather than size_t] to all those you mention. After that I got more errors that I can't recall now but was much more cryptic. I did updateMethods and added the mixin but things wern't working so I gave up. Seems like a nice idea, although, the downside that I see is one doesn't get encapsulation.
Aug 31 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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 appears to the 
 user and the compiler as an ordinary function - which is 
 generally good. As such it is eligible for UFCS. I would not 
 recommend this sort of coding, but it's everyone's choice, 
 methods or not.

 Likewise, methods can be overloaded (like here 
 https://github.com/jll63/openmethods.d/blob/1.0.0-rc.1/examples/matrix/source/matrix.d#L12).

 A current limitation is that default arguments are not 
 supported (yet), although I think it's just a matter of 
 putting the effort in.

 UFCS interacts nicely with methods because you can say 
 a.plus(b) even if 'plus' is an open method.
I can submit this as an issue on the github page, but I figured I'd mention it here in case there was some easy fix. 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: ..\..\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 implicitly convert expression dim of type ulong to uint ..\..\dubFolder\openmethods.d-1.0.0-rc.1\source\openmethods.d(1177,23): Error: c annot implicitly convert expression h of type ulong to uint dmd failed with exit code 1. The error at line 1076 can be fixed by changing the type of dim in the function to size_t. I couldn't fix the other errors. I tried having the hash function return size_t also, but that just causes other problems.
I was getting similar errors and simply added a cast(size_t)[used in the indexing, as he used ulongs for indexes rather than size_t] to all those you mention. After that I got more errors that I can't recall now but was much more cryptic. I did updateMethods and added the mixin but things wern't working so I gave up. Seems like a nice idea, although, the downside that I see is one doesn't get encapsulation.
It's fixed now, in master and in release v1.0.0-rc.2. Actually not getting encapsulation is good. With vfuncs, if you want polymorphism you get access to private parts, need it or not. And most of the time you neither need nor want it. If you need polymorphism and privileged access, you should use a vfunc but it's usually a sign of bad design, because a vfunc is meant to be overridden. And the override won't have access to the private parts so you may end up changing access from private to protected and usually trouble follows. I can imagine legitimate cases though. Fox example, the DiagonalMatrix addition example. In that case you can write a public final member function that performs addition using privileged access and call that from the 2-method 'plus'. ANother approach is to write the fvunc - or the 1-method - in terms of the public interface. Usually it's feasible and yields a better design.
Aug 31 2017
parent reply EntangledQuanta <EQ universe.com> writes:
On Thursday, 31 August 2017 at 21:02:26 UTC, Jean-Louis Leroy 
wrote:
 On Thursday, 31 August 2017 at 20:42:36 UTC, EntangledQuanta 
 wrote:
 On Wednesday, 30 August 2017 at 18:16:47 UTC, jmh530 wrote:
 [...]
I was getting similar errors and simply added a cast(size_t)[used in the indexing, as he used ulongs for indexes rather than size_t] to all those you mention. After that I got more errors that I can't recall now but was much more cryptic. I did updateMethods and added the mixin but things wern't working so I gave up. Seems like a nice idea, although, the downside that I see is one doesn't get encapsulation.
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 windows?
 Actually not getting encapsulation is good. With vfuncs, if you 
 want polymorphism you get access to private parts, need it or 
 not. And most of the time you neither need nor want it.

 If you need polymorphism and privileged access, you should use 
 a vfunc but it's usually a sign of bad design, because a vfunc 
 is meant to be overridden. And the override won't have access 
 to the private parts so you may end up changing access from 
 private to protected and usually trouble follows.

 I can imagine legitimate cases though. Fox example, the 
 DiagonalMatrix addition example. In that case you can write a 
 public final member function that performs addition using 
 privileged access and call that from the 2-method 'plus'.
Yeah, but one should always be allowed to shoot themselves in the foot. You never know when you might do it. Maybe an alligator has attached itself to your foot and is about to drag you under water?
 ANother approach is to write the fvunc - or the 1-method - in 
 terms of the public interface. Usually it's feasible and yields 
 a better design.
Aug 31 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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 windows?
Only size issues. Two lines in fact, see https://github.com/jll63/openmethods.d/commit/b63a88132e639bb23bb7 b305f4457450f865c6a but errors can cascade. I ran a few examples using the current dmd on Windows. Worked OK. It would be nice to have the Windows equivalent of dev/run-everything, maybe someone can PR me that?
 Yeah, but one should always be allowed to shoot themselves in 
 the foot.
I agree, wholeheartedly. In C++, yomm11 has macros that you can use to make a specific override or an entire method friend of a class. But alas no friendship in D.
Aug 31 2017
parent reply EntangledQuanta <EQ universe.com> writes:
On Thursday, 31 August 2017 at 23:21:03 UTC, Jean-Louis Leroy 
wrote:
 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 windows?
Only size issues. Two lines in fact, see https://github.com/jll63/openmethods.d/commit/b63a88132e639bb23bb7 b305f4457450f865c6a but errors can cascade. I ran a few examples using the current dmd on Windows. Worked OK. It would be nice to have the Windows equivalent of dev/run-everything, maybe someone can PR me that?
I'll try again at some point. I haven't got around to messing with it again. I was testing it out on something and ran in to those errors, fixed them, then ran in to some more and just went a different direction. I will try to start using them more at some point as I think the concept, at least, can be useful. I haven't used it yet though to know just how useful. I like how it extends object functionality without having to mess directly with the objects. I think the more complex the project the more useful they become. What is good though is that one can mingle oop and openmethods and finding a proper balance should result in a simpler design.
 Yeah, but one should always be allowed to shoot themselves in 
 the foot.
I agree, wholeheartedly. In C++, yomm11 has macros that you can use to make a specific override or an entire method friend of a class. But alas no friendship in D.
Yeah, D does some weird things. For all it's power it just screws the pooch in certain cases that really casts a shadow on what might be a great design. Usually there are work-arounds, but they always fill like a kludge and require an excessive amount of code to do something that could be done very simple, all in the name of XXX(whatever XXX is: backwards compatibility, "safety"(no guns on the beach! PERIOD! Even if the beach is full of alligators! We don't want anyone shooting anyone else! Better that they be eaten by alligators!), or some other "excuse").
Aug 31 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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?
Sep 02 2017
parent reply EntangledQuanta <EQ universe.com> writes:
On Saturday, 2 September 2017 at 14:04:07 UTC, Jean-Louis Leroy 
wrote:
 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?
I'll try real quick again. I'll have to rewrite the code as I moved on but: When I just add the mixin and update(to main) I get the error openmethods.d(1432): Error: function `main` has no members main.d-mixin-15(15): Error: CTFE failed because of previous errors in _registerMethods 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? Removing that mixin from main allows it to compile(but I haven't created any methods yet). You might look in to adding updateMethods in a static this() since it will be ran per process and do everything necessary, I think. After a few stupid bugs by me, I was able to get it to work! Pretty much a drop in replacement! I didn't do anything fancy, very basic, but it did work. It's not a real test but does show it can, for the most part, replace traditional code. Strangely enough, I had a protected member that I was using and it works, I guess because I defined the openmethod in the same module. I changed it to private and it worked too. So the issues about encapsulation I thought about before may be irrelevant as long as the openmethods are used in the same module(which is a nice feature of D). So, everything looks good on my end. Once I get around to creating something new or rewriting some old stuff I'll try to use them more and see what happens.
Sep 02 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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. The README.md says "Every module that declares methods or define implementations must include the following line". Ah yes the ddoc. I should update it. Also I think I should allow the mixin to silently do nothing in this case. Good catch.
 You might look in to adding updateMethods in a static this() 
 since it will be ran per process and do everything necessary, I 
 think.
Alas it won't work. Method registration is done via static ctors and they have to run - all of them - before updateMethods can do its work. In simple, one-module programs updateMethods in a static ctor will work, but in general it won't.
 Strangely enough, I had a protected member that I was using and 
 it works, I guess because I defined the openmethod in the same 
 module. I changed it to private and it worked too. So the 
 issues about encapsulation I thought about before may be 
 irrelevant as long as the openmethods are used in the same 
 module(which is a nice feature of D).
Neither the methods nor their overrides enjoy special privileges. Unless the override (i.e. the thing preceded by method) is a static member function? But I don't think so. Currently my code just scans the direct member of the module in which mixin(registerMethods) is called. Although I could change that, thus giving privileged access to some overrides. Could be useful for 1-methods. But anyway, probably there's something you don't notice...hmmm...can you share that code? Thanks for the feedback.
Sep 02 2017
parent EntangledQuanta <EQ universe.com> writes:
On Saturday, 2 September 2017 at 21:16:50 UTC, Jean-Louis Leroy 
wrote:
 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. The README.md says "Every module that declares methods or define implementations must include the following line". Ah yes the ddoc. I should update it. Also I think I should allow the mixin to silently do nothing in this case. Good catch.
 You might look in to adding updateMethods in a static this() 
 since it will be ran per process and do everything necessary, 
 I think.
Alas it won't work. Method registration is done via static ctors and they have to run - all of them - before updateMethods can do its work. In simple, one-module programs updateMethods in a static ctor will work, but in general it won't.
hmm, surely there is a mechanism which can be used? Possibly hooking in to druntime or some other hack? Not that it's a big deal but if you could get off the dependencies then it would be a sort of "compiler solution".
 Strangely enough, I had a protected member that I was using 
 and it works, I guess because I defined the openmethod in the 
 same module. I changed it to private and it worked too. So the 
 issues about encapsulation I thought about before may be 
 irrelevant as long as the openmethods are used in the same 
 module(which is a nice feature of D).
Neither the methods nor their overrides enjoy special privileges. Unless the override (i.e. the thing preceded by method) is a static member function? But I don't think so. Currently my code just scans the direct member of the module in which mixin(registerMethods) is called. Although I could change that, thus giving privileged access to some overrides. Could be useful for 1-methods. But anyway, probably there's something you don't notice...hmmm...can you share that code?
In D, encapsulation is voided at the module level. So private members are public to the module. struct S { private int x; } void foo(S s) { writeln(s.x); } works. If foo is declared outside the module it will fail. It's like friend in C++ but automatic and per module. Pretty nice but that is about as far as it goes in D. My code was pretty simple. I couldn't share it all because it's too large, but I simply replaced a single member with an open method. It had a few lines of code. One was accessing a protected member, which I changed to private... all compiled. Then I remembered about D's encapsulation rules for the module. So that nullified my issues that I though openmethods might have. So, I think, in fact, this might be a pretty good solution to many problems. It allows extensibility without tying the methods to the classes directly. I'm still imagine encapsulation will be an issue for larger designs since the openmethods won't be defined in the same module, but I haven't used them enough to know what kinda faults will creep up yet. I haven't used openmethods enough to really see their power but hopefully with this solution I can ;) Thanks!
Sep 02 2017
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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 - which is generally 
 good. As such it is eligible for UFCS. I would not recommend 
 this sort of coding, but it's everyone's choice, methods or not.

 Likewise, methods can be overloaded (like here 
 https://github.com/jll63/openmethods.d/blob/1.0.0-rc.1/examples/matrix/source/matrix.d#L12).

 A current limitation is that default arguments are not 
 supported (yet), although I think it's just a matter of putting 
 the effort in.

 UFCS interacts nicely with methods because you can say 
 a.plus(b) even if 'plus' is an open method.
I had a chance to try out what I had suggested above and it behaves exactly as I would have expected (i.e. it prints the line "lassie.kick(): ctbark"). You seemed to emphasize UFCS in your response, but that really wasn't what I was intending to focus on. I just as easily could have re-written Dog as below and compiled the program and it would have printed the same thing. Similarly, any Dog or Pitbull type that call kick would return "ctbark", just Animals would return the original results. class Dog : Animal { final string kick() { return "ctbark"; } } My point is one can easily mix your openmethods's dynamic dispatch and D's static dispatch. That seems like a great thing that you could emphasize. Simply stated: if you use openmethods, you're not forced to only use openmethods. If you know the type at compile-time, then you can use it. It's only if you want to dynamically dispatch it that you would need openmethods.
Aug 31 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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 - which is generally 
 good. As such it is eligible for UFCS. I would not recommend 
 this sort of coding, but it's everyone's choice, methods or 
 not.

 Likewise, methods can be overloaded (like here 
 https://github.com/jll63/openmethods.d/blob/1.0.0-rc.1/examples/matrix/source/matrix.d#L12).

 A current limitation is that default arguments are not 
 supported (yet), although I think it's just a matter of 
 putting the effort in.

 UFCS interacts nicely with methods because you can say 
 a.plus(b) even if 'plus' is an open method.
I had a chance to try out what I had suggested above and it behaves exactly as I would have expected (i.e. it prints the line "lassie.kick(): ctbark"). You seemed to emphasize UFCS in your response, but that really wasn't what I was intending to focus on. I just as easily could have re-written Dog as below and compiled the program and it would have printed the same thing. Similarly, any Dog or Pitbull type that call kick would return "ctbark", just Animals would return the original results. class Dog : Animal { final string kick() { return "ctbark"; } } My point is one can easily mix your openmethods's dynamic dispatch and D's static dispatch. That seems like a great thing that you could emphasize. Simply stated: if you use openmethods, you're not forced to only use openmethods. If you know the type at compile-time, then you can use it. It's only if you want to dynamically dispatch it that you would need openmethods.
Indeed I misunderstood. Well, I am very pleased that my stuff interacts well with the rest of the language - I strive for that. However, I found that it is difficult to get people to open their mind to the idea of open methods, initially. Unless they come from Lisp, polymorphism and membership are almost indissociable for them. I often have to jump three hurdles. 1/ They're multi-methods, and I never actually had a use for that. That is why I insist so much on openness in the article, and throw multiple dispatch in as a bonus only half way through. That's also why I call them "open methods" and not "multi-methods" or "open multi-methods". 2/ It's just function overloading. Hmmm, polymorphism? But once I get past that, it's actually a good thing. People know (more or less) how overload resolution (or partial template specialization for the more expert) works. So I don't need to explain the rules governing dispatch and ambiguities in an abstract way. Usually I just say "you already know which override will be picked - it's the same as with compile-time overload resolution". 3/ This one is specific to D - UFCS gives me the same thing. Hmmm, polymorphism again? But you see why I am very careful with anything that may obscure or confuse the message. I find the interaction of open methods and UFCS particularly cool when implementing the "call chain" idiom (e.g. a.plus(b).times(c).invert()).
Aug 31 2017
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 31 August 2017 at 16:55:17 UTC, Jean-Louis Leroy 
wrote:
 Indeed I misunderstood.

 Well, I am very pleased that my stuff interacts well with the 
 rest of the language - I strive for that. However, I found that 
 it is difficult to get people to open their mind to the idea of 
 open methods, initially. Unless they come from Lisp, 
 polymorphism and membership are almost indissociable for them. 
 I often have to jump three hurdles.
I can see that it's a uphill battle, but there's a lot to like about it as well for those who listen. Maybe it would be a good idea to allow the method to take an argument, like method(Animal), then you could mixin string kick(virtual!Animal); without having to define kick. I think the ideal would be if you could just write something like below: string(Animal) string kick(virtual!Dog dog) { return "bark"; } but I don't really know how to get that to work.
Aug 31 2017
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
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: https://github.com/jll63/openmethods.d/blob/master/examples/acceptnovisitors/source/app.d
Thanks for this library. Just a suggestion. Would it possible to use ` openmethod` instead of ` method`?
alias openmethod = method; Atila
Aug 31 2017
parent reply aberba <karabutaworld gmail.com> writes:
On Thursday, 31 August 2017 at 10:30:38 UTC, Atila Neves wrote:
 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: https://github.com/jll63/openmethods.d/blob/master/examples/acceptnovisitors/source/app.d
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 it unique.
Aug 31 2017
next sibling parent Jean-Louis Leroy <jl leroy.nyc> writes:
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 it unique.
After tightening a few screws, the library now supports static and selective imports.
Aug 31 2017
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Thursday, 31 August 2017 at 11:39:30 UTC, aberba wrote:
 On Thursday, 31 August 2017 at 10:30:38 UTC, Atila Neves wrote:
 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: https://github.com/jll63/openmethods.d/blob/master/examples/acceptnovisitors/source/app.d
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 it unique.
import otherpackage: funkyMethod = openmethod; import openmethod: openmethod = method; Or use the fully qualified name. Either way, nothing that can't be dealt with by D's modules as they are now. Atila
Aug 31 2017
parent jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 31 August 2017 at 13:30:27 UTC, Atila Neves wrote:
 import otherpackage: funkyMethod = openmethod;
 import openmethod: openmethod = method;

 Or use the fully qualified name. Either way, nothing that can't 
 be dealt with by D's modules as they are now.


 Atila
There are no limits to his criticism. If there are conflicts with method, then what happens when someone writes another project with openmethod as a UDA. I don't think it needs to get changed.
Aug 31 2017
prev sibling parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
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 something has to be done at the beginning, we have a tool for that: static this (on module level). The mixin(registerMethods); at the top should therefore mix in. static this() { updateMethods(); } It's never wrong: Calling it in main, too, will at most be redundant. You can still call it manually, but for the part of main, you cannot inadvertently forget it. You can still have static this in that module as you may have multiple static this.
Aug 30 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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 something has to be done at the beginning, we have a tool for that: static this (on module level). The mixin(registerMethods); at the top should therefore mix in. static this() { updateMethods(); } It's never wrong: Calling it in main, too, will at most be redundant. You can still call it manually, but for the part of main, you cannot inadvertently forget it. You can still have static this in that module as you may have multiple static this.
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 into it. Thanks for the suggestion...
Aug 30 2017
parent reply jmh530 <john.michael.hall gmail.com> writes:
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 into it. Thanks for 
 the suggestion...
Ali had suggested something similar[1]. I think your concern was that it would get called multiple times, but shared static module constructors runs once a program (static module constructor runs once per thread). [1] http://forum.dlang.org/post/okljj1$ktb$1 digitalmars.com
Aug 30 2017
parent reply Jean-Louis Leroy <jl leroy.nyc> writes:
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 into it. Thanks for 
 the suggestion...
Ali had suggested something similar[1]. I think your concern was that it would get called multiple times, but shared static module constructors runs once a program (static module constructor runs once per thread). [1] http://forum.dlang.org/post/okljj1$ktb$1 digitalmars.com
Ah yes...So the problem is that registerMethods emits static ctors that fill data structures representing the methods and the specializations. They have to run - all of them - before updateMethods. Thus, sadly Q's suggestion won't work.
Aug 30 2017
parent Jean-Louis Leroy <jl leroy.nyc> writes:
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 anybody thought of 
 putting it in registerMethods. It might work. I'll look into 
 it. Thanks for the suggestion...
Ali had suggested something similar[1]. I think your concern was that it would get called multiple times, but shared static module constructors runs once a program (static module constructor runs once per thread). [1] http://forum.dlang.org/post/okljj1$ktb$1 digitalmars.com
Ah yes...So the problem is that registerMethods emits static ctors that fill data structures representing the methods and the specializations. They have to run - all of them - before updateMethods. Thus, sadly Q's suggestion won't work.
Yes I remember now...even if we arrange to put the call to updateMethods in its own static ctor, coming after all the other static ctors, we don't know if there will be more modules with more methods afterwards. So we would have to do the updateMethods work each time, lest this module is the last. And updateMethods is costly: not only does it figure out all the dispatch tables, it also calculates a perfect hash (if mptr is used) using a random algorithm.
Aug 30 2017