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.

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...

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.

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

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.

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.

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

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.

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.

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()).