Proposal: Extension Methods

[Nick Sabalausky]

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