Microsoft C# 3.0 / VB.NET 9.0 / CLR functionality that enables "adding methods" to existing classes -- a foundational language technology supporting LINQ (LanguageIntegratedQueryProject).
See "Extension Methods" heading under http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp#linqprojec_topic3
(It's the next section after "Lambda Expressions and Expression Trees".)
Is...
- SyntacticSugar, in that ExtensionMethods really are (just) static methods, and can be called as such. Their "ExtensionMethods"-ness is that they provide a convenient "object method invocation"-like syntax for new methods added to existing (presumably unchangeable) classes.
- All language features are SyntacticSugar, this is a meaningless comment.
- Is a weak form of AspectOrientedProgramming: One that allows you to "add methods" to existing (presumably unchangeable) classes. (But you can't intercept method calls, or access private fields.)
- It has nothing to do with AspectOrientedProgramming, it's nothing more than a way to simulate new custom methods onto existing framework objects that you can't edit. Rather than create a ton of utility classes and having to remember them, as everyone does, you create your utility classes with a special syntax that adds those methods object you're trying to extend, like maybe adding a method plural() to the string class. It's intent is to appear as an ordinary instance method on a class you can't actually extend. The main benifit being the appearance of being able to extend any class with custom methods, and not having to remember some homebrew convention for utilities. It's a feature copied from smalltalk, as are most OO features.
Really, since the foo.bar() calling convention is just syntactic sugar on fooClass::bar(foo), it is a wonder that all languages based on the foo.bar() calling convention don't support the ExtensionMethod? approach (and likewise, don't support static-style calling of member methods). The only oddity is that it completely dements namespaces - but if one is already including all the namespaces into the local level, that problem goes away.
It also allows programmers to think a little more "object-orientedly" when dealing with classes that they can't modify directly. OOP developers are always taught to avoid producing functions that perform a laundry-list of operations on object X unless the function is a member of X - but in cases where X is not modifiable by the developer, that goal is unattainable.
Interesting to note that MultiMethods avoid this problem entirely, subsuming the characteristics of both ExtensionMethods and InstanceMethods?.
PrototypeBasedProgramming (and other systems in which classes are not immutable) also avoid this problem.
- What "problem"? In Javascript, Python, and Smalltalk, you don't need special syntactic sugar. You build an "extension" to an existing class, where the extension contains a group of methods. I consider it bad form to make changes to the "shape" of an object in its extension, but that's seldom a difficult restriction. A class definition is simply a combination of a shape specifier (often a "constructor" in the jargon of Javascript and Python) and an "extension", containing a group of methods. These extensions have readily-definable prerequisite and dependent relationships and are readily and effectively managed with source code management systems. EnvyDeveloper is a good example of this in Smalltalk and Java.
Should the use of extension methods to implement something like mixins be considered good or bad?
(See: http://www.zorched.net/2008/01/03/implementing-mixins-with-c-extension-methods/ or many other similar sites)
FebruaryZeroSix
Extension Methods