Proposal: Extension Methods

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:g08fha$2e5$1 at digitalmars.com...
>I thought I had seen discussion on something like this back when the 
>"Functions as Array Properties" feature was introduced, but I just did a 
>search and didn't see much of anything. So sorry if this has been discussed 
>to death before.
>
> I propose adding to D a feature that C# calls extension methods. These are 
> similar to D's "Functions as Array Properties", but provide more control 
> and flexibility.
>
> For any function that's not a member of a class (and maybe also static 
> member functions of classes), if you add the modifier "extend" or "this" 
> to first argument of the function declaration like this:
>
> // Normal Function
> void Foo(MyClass arg) {/*...*/}
>
> // Extension Method (I'm proposing either of these, but not both):
> void Foo(this MyClass arg) {/*...*/} // C#-style
> void Foo(extend MyClass arg) {/*...*/} // Might be more readable
>
> (Although, there wouldn't actually be overloading based soley on whether 
> or not it's declared as an extension method. (Or would there? Probably 
> not.))
>
> Then that allows you to call Foo like this:
>
> auto obj = new MyClass();
>
> // Always allowed
> Foo(obj);
>
> // Allowed if and only if Foo has been declared
> // using the above extension method syntax.
> // But regardless, Foo never has access to private members
> // of MyClass, since it still isn't a true member.
> obj.Foo();
>
> This should also be allowed for primitives:
>
> void Foo(extend int arg);
> int myInt = 7;
> myInt.Foo();
> 5.Foo(); // Might interfere with parsing of floating-point literals, 
> though.
>
> This has two advantages over the current "Functions as Array Properties" 
> feature:
>
> 1. It supports more than just arrays (obviously).
> 2. The special syntax is only available if the function's author intends 
> it as a non-member "extension" to the given type.
>
> Possible modifications to this proposal:
>
> - If advantage #2 is deemed to be an unwarranted concern, I'd be happy to 
> at least have the current "Functions as Array Properties" feature extended 
> to all types, not just arrays.
>
> - Maybe declaring a function as an extension method would *require* it to 
> be called using extension method syntax. Although under this arrangement, 
> if you wanted a function to be callable via either syntax (but would this 
> ability really be desirable?), that would require a function overload or a 
> messy kludge like using "maybe_extend" instead of "extend".
>

I was just looking through the documentation on some of the Phobos stuff 
that's new in D2, and at pipe! and compose! in particular. This is kind of 
nice (from docs):

int[] a = pipe!(readText, split, map!(to!(int)))("file.txt");

Not to nag about extension methods (well, ok, yes: to nag ;) ), but with 
extension methods (regardless if they're explicit or implicit), that could 
be cleaned up to:

int[] a = "file.txt".readText().split().map!(to!(int)))();

Granted, this doesn't actually create a new composite function. But for 
cases like this one where a reusable composite function isn't needed, it 
increases readablity quite a bit.

It would also allow extra paramaters to be specified without having to turn 
them into template parameters:

int[] a = "file.csv".readText().split(",").map!(to!(int)))();

Maybe that might break functional-style code if that's what the coder is 
going for (not sure, my functional experience is limited), but in that case 
they can still fall back on pipe!.