|
Shog9 wrote: If you're a newbie programmer, then it doesn't matter - it'll suck. If you're just new to C#, then you'll want to play around with the tools, and it'll probably still suck.
Yeah, I guess it's always good to have newbies around to laugh at! 
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
Confusion.
a) People talk about them becoming members of the class, they do no such thing, they just look like it.
b) Someone may ask "How do I do blah with X?"
Someone else may answer "Just use X.blah()" without realizing that blah is an Extension Method (perhaps internal to the company or some third-party library that the asker doesn't have).
The original asker will look in intellisense and maybe even check the documentation, but not find it.
Extension Methods are user-hostile.
|
|
|
|
|
Yeah, a bad idea implemented poorly.
What I finally decided to do was to put each Extension Method I write (I have four, none of them Earth-shattering) in its own namespace, so you only get what you ask for.
I don't use Linq either.
The only reason to use .net 3.5 is HashSet, and even that is underwhelming -- no operators! I'm guessing they only added it because they use it in Linq and didn't want to be accused of using undocumented features (again).
Sunny Ahuwanya wrote: forcing ME to write bad code.
Use them as regular static methods.
|
|
|
|
|
Extension methods are just like any other language feature...they have the ability to be misused/abused (and not just from newbies, but by anyone). I don't think that's a good reason to not include a feature or we would end up writing assembly again.
How do extension methods force you to write bad code? If you don't want to use them, don't use them. It's that simple.
Yes, there should be more guidance on how to properly use/write extension methods (which is coming) and possibly some better compiler support to enforce that. I disagree with the ability to add extension methods in the same namespace as one that's defined by Microsoft. This isn't actually polluting a namespace but rather polluting a type, but that's kind of the idea behind extension methods. BTW, other languages have similar features as well and are usually called Mix-Ins.
The thing to remember about extension methods is that they are nothing more than an alternate syntax for calling a static method on a static class. They are defined in exactly the same way (with the addition of the "this" keyword in the parameter list) and compile to the exact same IL as if you were to call it the "normal" way (i.e., as a static method on a static class and pass in the object you want to modify/act on). Calling it as an extension is a more natural syntax, but it's all syntax sugar/compiler magic.
Extension methods do not have access to the internal state or variables of the class they are extending. You also can't use an extension method with the same signature as a native method...you can declare one but there is no way to actually override the native method with your extension and it won't show up as an available method in intellisense so there is no way to call it except as a static method on a static class, in which case you no longer have the extension syntax and it's completely clear which method is being called.
Scott Dorman Microsoft® MVP - Visual C# | MCPD
President - Tampa Bay IASA
[ Blog][ Articles][ Forum Guidelines]
Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
|
|
|
|
|
I want C# that helps me write less buggy code. This can be accomplished by integrating some Spec# features like [Pure], [Immutable], etc.
I want to be able to write yield return someEnumerable;.
I want a terse syntax for enumerables, now that they're everywhere with LINQ. private IEnumerable<Foo> SomeFunc(IEnumerable<Bar> input) { ... } is just too wordy.
modified on Wednesday, October 1, 2008 6:39 PM
|
|
|
|
|
I'd really really really like to see absolutely no changes whatsoever. Seriously.
"It's so simple to be wise. Just think of something stupid to say and then don't say it."
-Sam Levenson
|
|
|
|
|
Me too.
I think they already degraded the language in C# 3 by adding extension methods and partial methods just to sell LINQ.
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
Sunny Ahuwanya wrote: I think they already degraded the language in C# 3 by adding extension methods
I think of them as of an improvement and use them.
|
|
|
|
|
Pawel Krakowiak wrote: I think of them as of an improvement and use them. Smile
Can anyone explain to me how extension methods are an improvement? Besides helping to sell LINQ and encouraging programmers to write code in a non-portable, non object oriented manner, what is the point of extension methods?
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
Sunny Ahuwanya wrote: non-portable, non object oriented manner
Hmm, that's interesting. Is it not part of the ECMA spec? Considering there's no runtime support required for extension methods, I can't see any other portability concerns. Or maybe you are considering them non-portable because the calling code won't compile without the presence of the source code containing the extension methods?
And yeah, they are non object oriented if you consider static methods in a static class non-object oriented as well.
|
|
|
|
|
On Portability:
1) Imagine if I had to port some C# code from one framework/platform to another.
Before C# 3.0, I'd had to make sure I have compatible libraries in the new framework. But now, I also have the added headache of figuring out where ALL the referenced extension methods in the code are and make sure they exist in the new framework (or write equivalent ones).
It doesn't help that extension methods share the same dot notation with regular methods. I can't tell what an extension method is just by looking at the call.
I'd have to write some tool that will check all referenced assemblies to point out the extension methods in the code.
2) Let's say I'm using LINQ's IEnumerable.Where extension method on a collection class someone else wrote, BUT I didn't realize the other developer had included a .Where regular method that returns an IEnumerable<t>. My code will compile superbly without any warnings. The best part is that this code will work for months until THE CONDITION that differentiates the developer's .Where method and the LINQ's .Where method occurs.
On Object Orientedness:
Developer A uses List.SingleOrDefault() extensively, developer B creates a new class derived from List but would like .SingleOrDefault() to work a little differently so that all the pre-existing code will work properly with objects derived from his new class. He's stuck. 
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
The methods implemented as part of IEnumerable are now intrinsic to the .NET framework. Any decent developer would avoid using identifiers already used in the framework. Your argument about IEnumerable.Where is the same as saying Developer B creates a new class called String... Simple solution, don't do that. Almost any language feature can be missused. Don't missuse them.
|
|
|
|
|
Not every developer writing C# code targets the .NET framework. I used IEnumerable.Where as an example which everyone would understand but it could be any set of extension methods from XYZ company.
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
This raises a good point about extension methods. They are not object oriented. If someone wants to write an extension method, then they should write a subclass to the object you want. Then add the desired methods.
But, it sounds like LINQ is a (very) popular feature. And, the only way to support LINQ is by extension methods. Then, maybe the question should be is should MS not allow the public (those not writing directly for MS C#) to create extension methods? Keep them internal to the Microsoft C# team for specific requirements of the language (like LINQ).
|
|
|
|
|
Sunny Ahuwanya wrote: Can anyone explain to me how extension methods are an improvement?
They allow me to simply add new functionality to the existing classes, including Framework classes and I personally find them useful. I use them with Enums and String to provide some new functionality needed in a project. So their exact purpose is an improvement for me, there's nothing to add.
|
|
|
|
|
Pawel Krakowiak wrote: add new functionality to the existing classes
They do nothing of the sort!
|
|
|
|
|
They absolutely do! Look at IEnumerable...EVERY type that implements IEnumerable DOES INDEED get the full functionality of all extension methods written for IEnumerable (so long as the proper using statement(s) are included). You don't have to "implement" the extension methods on each class that implements IEnumerable...the extension methods absolutely do add new functionality without you having to do any extra implementation. And that functionality is accessed through class INSTANCES...not static methods or utility types.
You anti-progressive types drive me nuts sometimes...get off your high horse and USE the tools at your disposal. You might find that you actually like them.
|
|
|
|
|
Personally I love the extensions methods for the collection types, like List<t>[^]. They provide some very powerful and useful ways to manipulate data. It's a big productivity improvement, IMO.
|
|
|
|
|
But using them as Extension Methods is no more "powerful and useful" than using them as regular static methods.
The "Extension Method-ness" isn't what makes the methods "powerful and useful".
|
|
|
|
|
Jon Rista wrote: anti-progressive types
No, I'm a pedantic type!
I do use one or two Extension Methods I've written.
I know what Extension Methods do, and "adding functionality to classes" isn't it.
They simply masquerade as class members.
They are still just static methods and can be used as such.
They have absolutely zero effect on the class involved.
Any benefits (over classic static usage) they offer are purely superficial.
I'm not saying they don't work. I'm not saying that the static methods that implement them aren't useful.
I (and I'm not the only one) think that having a static method look like a class method is a bad idea; they seem to break orthogonality for one thing.
When I see a snippet of code posted here or elsewhere (where Intellisense isn't involved) I can't tell one from the other.
Other than that, I don't like the implementation; the change to the syntax was unnecessary, the developer should be allowed to put the attribute on the method directly.
|
|
|
|
|
Jon Rista wrote: And that functionality is accessed through class INSTANCES...not static methods or utility types.
This is exactly why I said extension methods should come with a warning tag.
Sunny Ahuwanya
"The beauty of the desert is that it hides a well somewhere"
-- Antoine de Saint Exupéry
|
|
|
|
|
PIEBALDconsult wrote: They do nothing of the sort!
string lookingFor = "Wash";
lookingFor.ToSqlLike(SqlLikePlacement.Front);
lookingFor.ToSqlLike(SqlLikePlacement.Middle);
lookingFor.ToSqlLike(SqlLikePlacement.End);
I understand I missed something and the above code is possible without extension methods and without creation of a new class?
|
|
|
|
|
Bad example. How is that better than:
<br />
lookingFor = "%" + lookingFor ;<br />
lookingFor = lookingFor + "%" ;<br />
lookingFor = "%" + lookingFor + "%" ;<br />
The standard way is much clearer (at least in this case).
|
|
|
|
|
PIEBALDconsult wrote: How is that better than:
lookingFor = "%" + lookingFor ;
lookingFor = lookingFor + "%" ;
lookingFor = "%" + lookingFor + "%" ;
The standard way is much clearer (at least in this case).
I was using the example code to filter SubSonic queries (which look much like LINQ extension methods) and it definitely looks better there.
By the way, you know that C# strings are immutable and the above code you provided creates additional string objects just to discard them right after they are created and make them wait for the garbage collector to do its job?  Very inefficient, I'd say.
|
|
|
|
|
Yes, I know that, but the implementation of SqlLike (or whatever) may be no better, and adds a function call as well (which may or may not get inlined). And perhaps pre-condition checking as well.
Plus that's only true of the last example.
There's no way to tell which is "more efficient" from just looking at the examples, and such concerns are likely to be needless anyway.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
