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