July 03, 2012
> Thanks to C++ for inspiration, I even have proposal for such syntax!
>
>        obj.free myFunc( args )
>        obj.member myFunc( args )
>
>
How about:

obj.myFunc( args ); // calls member function, even if free function exists
myFunc( obj, args ); // calls free function, even if member function exists

That is the current behavior.  :-)

Regards
- Puneet


July 03, 2012
Jonathan M Davis:

> Yes, but as I said, if it _didn't_ select the member function when there was a
> conflict, it would be impossible to call the member function whenever there was
> a conflict. There is no way to indicate that you mean a member function rather
> than a free function. The normal way to do that is to use member function call
> syntax, and UFCS allows you to then use that for free functions. With conflicts
> between free functions, you can do path.to.func or other.place.func instead of
> just func, but with a member function, that's not possible. So, without adding
> new syntax to the language,

I understand. This is Nick Sabalausky example:

> import std.stdio;
>
> void bar(Foo f) {
>     writeln("UFCS");
> }
>
> struct Foo {
>     void bar() {
>         writeln("Member");
>     }
> }
>
> void main()
> {
>     Foo f;
>     f.bar();
> }


So let's assume the language gives an compile error here, because there is a conflict. If you want to call the free function you use bar(f). If you want to call the bar method of Foo, you can't, because it's ambiguous, and as you say there is no alternative (simple) syntax to specify you want the method of Foo.

This is a limitation. But is this a problem? If you want to call Foo.bar then you don't import the free function bar in the current scope. How often do you want to keep both the free function and a method with the same name and you wan to call the method?

So maybe it's worth accepting this limitation, to reduce confusion for the people the read the code.

Bye,
bearophile
July 03, 2012
On Tuesday, July 03, 2012 21:55:47 bearophile wrote:
> So maybe it's worth accepting this limitation, to reduce confusion for the people the read the code.

I would give a resounding no on that one. The confusion on how to actually manage to be able to use your member function would t hen be even greater, and if you need lots of other stuff from the module which provides the offending free function, then _not_ importing it becomes a royal pain. I think that the current approach works just fine.

- Jonathan M Davis
July 03, 2012
On 07/03/2012 09:55 PM, bearophile wrote:
> Jonathan M Davis:
>
>> Yes, but as I said, if it _didn't_ select the member function when
>> there was a
>> conflict, it would be impossible to call the member function whenever
>> there was
>> a conflict. There is no way to indicate that you mean a member
>> function rather
>> than a free function. The normal way to do that is to use member
>> function call
>> syntax, and UFCS allows you to then use that for free functions. With
>> conflicts
>> between free functions, you can do path.to.func or other.place.func
>> instead of
>> just func, but with a member function, that's not possible. So,
>> without adding
>> new syntax to the language,
>
> I understand. This is Nick Sabalausky example:
>
>> import std.stdio;
>>
>> void bar(Foo f) {
>>     writeln("UFCS");
>> }
>>
>> struct Foo {
>>     void bar() {
>>         writeln("Member");
>>     }
>> }
>>
>> void main()
>> {
>>     Foo f;
>>     f.bar();
>> }
>
>
> So let's assume the language gives an compile error here, because there
> is a conflict.

There is no conflict. The method takes precedence.

> If you want to call the free function you use bar(f). If
> you want to call the bar method of Foo, you can't, because it's
> ambiguous, and as you say there is no alternative (simple) syntax to
> specify you want the method of Foo.
>
> This is a limitation. But is this a problem?

Certainly.

> If you want to call Foo.bar
> then you don't import the free function bar in the current scope. How
> often do you want to keep both the free function and a method with the
> same name and you wan to call the method?
>

Every time you want the free function to be a generic implementation
that works for everything and the method to be a specialisation for the
respective type if present.

The question you should be asking is: "How often do you want to keep
both the function and a method with the same name and don't want to
call the method?" I cannot think of a single case.

> So maybe it's worth accepting this limitation, to reduce confusion for
> the people the read the code.
>

It does not do that.

It does not matter whether or not a function is a member function. Why
would it make any difference?
1 2
Next ›   Last »