Proposal: Extension Methods

[Dee Girl]

Nick Sabalausky Wrote:

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

This is big problem with functional style in D! D does not have currying. Unfortunate you can not write split(",") and obtain a new function. Maybe language in future can accept split(_, ",") meaning function that takes one argument and passes to split in first position and "," in second position. Dee Girl