Proposal: Extension Methods

[Fawzi Mohamed]

On 2008-05-12 06:03:01 +0200, "Nick Sabalausky" <a at a.a> said:

> 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 find this kind of extensions nice, they allow to work around library 
misdesign (or to handle special cases) in a much better way.
Dynamic language often can do it.
A static language language that had the idea of a posteriori extension 
very well developed:
	http://www.aldor.org/docs/HTML/chap10.html
(the language itself is basically dead but for other reasons)
The question is how difficult is their implementation, and how useful 
they really are, as these  can lead also to bad design if overused, but 
well used they are really nice.

Fawzi