0

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?

3

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 Nov 23 '13 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 accept IEnumerable<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 Nov 24 '13 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's public (or sometimes internal) methods. So you can't mess with its internal state using extension methods, even though it looks like you should be able to. – Bobson Nov 25 '13 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.