Proposal: Extension Methods
janderson
askme at me.com
Mon May 12 20:18:20 PDT 2008
Nick Sabalausky wrote:
> "janderson" <askme at me.com> wrote in message
> news:g08j47$8cs$1 at digitalmars.com...
>> Walter talked about the proposal for interchangeable method/functions. It
>> was talked about at the D conference. I'm not sure how much resistance he
>> got to the idea.
>>
>> I'm a big fan on interchangeable function/methods without the additional
>> syntax as it would push the flexibility to the user rather then the lib
>> designer. I have mentioned it several times.
>>
>
> Maybe someone can point out that I'm worrying over nothing, but here's my
> main concern about that:
>
> Unless I misunderstand the "interchangeable methods/functions" concept, that
> means that the following code would result in conflict issues with "Foo":
>
> // Note: sample code untested
> module moduleA
> {
> class A
> {
> public void Foo() {}
> }
> void Bar() {}
> }
>
> module moduleB
> {
> import moduleA;
>
> void Foo(ref A a) {}
> void Bar() {}
> void main(char[][] args) {}
> }
>
> In this example, there is a conflict with Bar(). But this is OK, since, in
> main() we can disambiguate like (I might be forgetting the details here, but
> it's something like this):
>
> moduleA.Bar(); // moduleA's Bar()
> .Bar(); // moduleB's Bar()
>
> // On a totally separate note, what does this do?
> // Does this assume one Bar() or the other,
> // or is it disallowed due to ambiguity?
> Bar();
>
> So with Bar() we're ok. But how would you disambiguate Foo() when using
> member function syntax?
>
> auto a = new A();
>
> // moduleA:
> a.moduleA.Foo(); // Makes it seem like "moduleA" belongs to "a"
> moduleA.a.Foo(); // Makes it seem like "a" belongs to "moduleA"
> a.A.Foo(); // Makes it seem like "A" is a member of "a"
> A.a.Foo(); // Makes it seem like "a" is a static member of "A"
> a.(moduleA.Foo)(); // Kinda ugly, but maybe?
> a.(A.Foo)(); // Kinda ugly, but maybe?
>
> // moduleB:
> a..Foo(); // As Earnest P. Worrell would say, "Eeeewwww..."
> .a.Foo(); // Makes it seem like the scope resolution
> // operator is referring to "a" instead of "Foo"
> a.(.Foo)(); // Kinda ugly, but maybe?
>
> Seems to me you could solve that three ways, none of which seem ideal:
>
> 1. Disallow member function syntax when a conflict like this exists. So all
> of a sudden, I can't call A's own member function with member function
> syntax. Yuck.
>
> 2. Force member function syntax to mean moduleA's Foo() and non-member
> syntax to mean moduleB's Foo(). But this could result in accidentally
> calling the wrong Foo(), especially when people are accustomed to being able
> to use "obj.Func();" and "Func(obj);" interchangeably.
>
> 3. Generate a "function redefined" compile-time error. But this is
> inconsistent with Bar().
>
>
If the code has been multiply defined, the compiler should respond that
it does not know what version to use and ask for a qualifier.
What that qualifier is I don't know. Perhaps:
Foo((a));
and
(a).Foo();
-Joel
More information about the Digitalmars-d
mailing list