Missing extension methods in 3.5 [modified]
-
Ive got a class library project set up, and its set for 3.5 framework.(Im actually following a tutorial online). However, when I reference a IList, I get no extension method in the list, such as ToArray. Im defining an object as:
IList<int> results = new List<int>();
// populate listvar convertedtoArray = results.ToArray<int>();
But I can compiler error because ToArray doesnt exist. Even though Im using the System.Collections.Generic namespace. Any ideas? Mark
modified on Thursday, January 22, 2009 5:27 PM
You must have a reference to the assembly in your project, not just a using statement.
only two letters away from being an asset
-
You must have a reference to the assembly in your project, not just a using statement.
only two letters away from being an asset
-
Ive got a class library project set up, and its set for 3.5 framework.(Im actually following a tutorial online). However, when I reference a IList, I get no extension method in the list, such as ToArray. Im defining an object as:
IList<int> results = new List<int>();
// populate listvar convertedtoArray = results.ToArray<int>();
But I can compiler error because ToArray doesnt exist. Even though Im using the System.Collections.Generic namespace. Any ideas? Mark
modified on Thursday, January 22, 2009 5:27 PM
using System.Linq;
and reference System.Core
Eslam Afifi
-
System.Collections.Generic sits in the System.Core assembly, which is referenced by default. :^)
No, only part of it. System.Collections.Generic.List<> is in mscorlib assembly, while System.Collections.Generic.Queue<> is in System assembly.
Eslam Afifi
-
using System.Linq;
and reference System.Core
Eslam Afifi
-
You're welcome.
Eslam Afifi
-
using System.Linq;
and reference System.Core
Eslam Afifi
Therein lies a great deal of what I don't like about extension methods.
-
Therein lies a great deal of what I don't like about extension methods.
and what might that be?
only two letters away from being an asset
-
and what might that be?
only two letters away from being an asset
People not knowing where they are and not even knowing that they are extension methods. At least as regular static methods it's clearer that the method is not part of the type. Exension methods are a form of obfuscation. But that's just me.
-
People not knowing where they are and not even knowing that they are extension methods. At least as regular static methods it's clearer that the method is not part of the type. Exension methods are a form of obfuscation. But that's just me.
PIEBALDconsult wrote:
even knowing that they are extension methods.
VS shows extension methods with a different icon in intellisense, right?
Navaneeth How to use google | Ask smart questions
-
PIEBALDconsult wrote:
even knowing that they are extension methods.
VS shows extension methods with a different icon in intellisense, right?
Navaneeth How to use google | Ask smart questions
Not everyone uses VS. Snippets of code posted here don't have intellisense either. Nor do printouts Don't rely on the behaviour of any one tool.
modified on Friday, January 23, 2009 1:26 AM
-
Not everyone uses VS. Snippets of code posted here don't have intellisense either. Nor do printouts Don't rely on the behaviour of any one tool.
modified on Friday, January 23, 2009 1:26 AM
The semantics of an extension method are correct, and they increase code readability. They are certainly preferable than buggering up the type heirarchy with things like "MyListWithExtraStuff : List". They also allow you to extend any type which supports a particular interface, which is a powerful feature - almost like half-baked multiple inheritance.
myFoo.Baz(bar);Is Baz an extension method? Does it matter? As long as it "bazzes" as documented, then it is no different from a normal method.Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Entanglar: .Net game engine featuring automatic networking and powerful HLSL gfx binding. -
The semantics of an extension method are correct, and they increase code readability. They are certainly preferable than buggering up the type heirarchy with things like "MyListWithExtraStuff : List". They also allow you to extend any type which supports a particular interface, which is a powerful feature - almost like half-baked multiple inheritance.
myFoo.Baz(bar);Is Baz an extension method? Does it matter? As long as it "bazzes" as documented, then it is no different from a normal method.Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Entanglar: .Net game engine featuring automatic networking and powerful HLSL gfx binding.Mark Churchill wrote:
The semantics of an extension method are correct
Because they added those semantics.
Mark Churchill wrote:
they increase code readability
My opinion is that they do just the opposite.
Mark Churchill wrote:
any type which supports a particular interface
Just like regular static methods.
Mark Churchill wrote:
almost like half-baked multiple inheritance
You may be onto something there. Or maybe just on something. :-D
Mark Churchill wrote:
Does it matter?
Of course it makes a difference. Not to the original developer, not to the compiler, but when communicated between developers, particularly inexperienced ones. I'm well aware that I take the minority view on this and many other things, but I'm not the only one. Others [weasel words] have the same and other concerns. I do write an occasional extension method (see my recent "Untabify and Tabify"[^] article), but I try to make it clear that extension methods are in use.