According to WikiPedia
"Some languages do not support mixins on the language level, but can easily mimic them by copying methods from one object to another at runtime, thereby "borrowing" the mixin's methods. Note that this is also possible with statically typed languages, but it requires constructing a new object with the extended set of methods."
1) LinqExtensions static library functions ( .Where() ) applied to collections of regular objects (int[]) that implement IEnumerable do essentially this. They use a new object (LinqExtensions) to add the extended set of methods ( Where(),etc ).
Conclusion. LinqExtensions are mixins with all classes that support IEnumerable.
2) According to WikiPedia
"In object-oriented programming languages, a mixin is a class which contains a combination of methods from other classes. How such combination is done depends on language, but it is not by inheritance. If a combination contains all methods of combined classes it is equivalent to multiple inheritance."
By mixing ALL methods of classes that support IEnumerable ( List.HashCode, List.ToString, other List hierarchy baseline capabilities ), with ALL methods from the LinqExtensions static library ( .Where(), Max(), etc ) an equivalent to multiple inheritance is produced.
An equivalent to multiple inheritance is produced, yes or no?
1 Answer 1
No.
The methods are not added to IEnumerable
but are only available if the LinqExtensions
type is within scope. This means that in some parts of the code .Where
and its kin are available, and some parts they're not.
For Scala style mix-ins the methods are part of the mixed type and as such are available regardless of scope and can participate in subtyping checks.
Further, a requisite behavior for something to be called multiple inheritance involves actual inheritance. If you have two extension methods - one for IEnumerable
and one for List
no actual runtime dispatch occurs. If you have a List
, what extension method is invoked depends wholly on the compile-time type of the variable.
Beyond that, extension methods cannot extend the state of the object they extend (without inglorious hacks). When people talk about inheritance, they generally assume that you can add variables to a baseclass during inheritance.
So no - extension methods are not in any meaningful way an equivalence to multiple inheritance.
-
Can you think of any case where LinqExtensions is NOT in scope? It seems that adding using System.Linq; is the only criteria and that would do it for every possible scope. By adding using System.Linq; aren't you, for all practical purposes, adding those methods to IEnumerable?Andyz Smith– Andyz Smith2013年11月23日 23:17:58 +00:00Commented Nov 23, 2013 at 23:17
-
@AndyzSmith - For
LinqExtensions
it's not much of a concern. Everyone has it and it's available to everyone. But consider code written in the .NET 2.0 timeframe: code here can acceptIEnumerable<T>
but calls for.Where
fail. Reflection to find.Where
will fail. Casting to get.Where
fail. All of these would work if you were using real multiple inheritance or even traits. Yes, these are outliers but enough to disqualify the "all practical purposes" statement.Telastyn– Telastyn2013年11月24日 00:25:30 +00:00Commented Nov 24, 2013 at 0:25 -
+1 for
extension methods cannot extend the state of the object they extend
. They also can't modify it in any way that isn't permitted by the object'spublic
(or sometimesinternal
) methods. So you can't mess with its internal state using extension methods, even though it looks like you should be able to.Bobson– Bobson2013年11月25日 19:00:14 +00:00Commented Nov 25, 2013 at 19:00