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.

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.

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.

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

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/b63a88132e639bb23bb7cb305f4457450f865c6a 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").

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.

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

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.

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!