Extension Methods - Satan's favourite construct (controversial to nerds)
-
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
What, you don't like this code?
// Menu copy handler. If a control has focus and its an edit box, copy its text to the clipboard,
// otherwise if there's an active notecard instance, tell the notecard's view to do the copy to the clipboard.
protected void Copy(object sender, EventArgs args)
{
Program.GetFocusedControl().IfNotNull(ctrl =>
{
ctrl.Is(tb => tb.Copy());
}).Else(() => ActiveDocumentController.IfNotNull(notecard => notecard.NotecardView.Copy()));
};P Marc
Latest Article: C# and Ruby Classes: A Deep Dive
My Blog -
You see, without entering into an argument I see no benefit in the piece of code you show above. All you've done is got rid of a couple of lines of clear explicit code which guarantees that people can see what it does and what it does not do. What happens if an exception is thrown during iteration? You can't tell - depends on what the extension method does.
Regards, Rob Philpott.
Rob Philpott wrote:
I see no benefit in the piece of code you show above.
It may just be my opinion but I find this
collection.ForEach(item =>
{
//DoStuff
});more readable than
foreach(var item in collection)
{
//DoStuff
}or
foreach(SomeDependentObject item in collection)
{
//DoStuff
}or
for(int i = 0; i < collection.Count(); i++)
{
//DoStuff
}and so on and so forth. It seems more natural when I am coding. I am given the context (the collection) and then I run some action on it for each item.
Rob Philpott wrote:
What happens if an exception is thrown during iteration?
Well then an exception happens as it would with any of the iteration styles above.
Rob Philpott wrote:
You can't tell - depends on what the extension method does.
This is my point. If your extension is complicated and verbose you are doing it wrong. It should be simple and highly intuitive of what it is doing and any exceptions that are being passed in to the extension should not be captured by the extension but show up where the exception actually occurred. This is the nature of
staticclass and has nothing to do with extensions other than that is how you implement extensions.Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
Of sealed classes : ) I mean, really, why must I constantly check for DB Null when reading from a db. Just make it real null instead.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
Not quite with you, but on that note, if a quantity can have a DB Null its likely going to be a reference type or Nullable<> in which you can just do (reader[i] as int?) (reader["name"] as string) etc, and that will turn you DB nulls to .net nulls for you. If you use extensions here - why not. I use them on String to give me a traditional Left and Right function. I think it's when you start involving them in the system architecture that things start to do horribly wrong.
Regards, Rob Philpott.
-
What, you don't like this code?
// Menu copy handler. If a control has focus and its an edit box, copy its text to the clipboard,
// otherwise if there's an active notecard instance, tell the notecard's view to do the copy to the clipboard.
protected void Copy(object sender, EventArgs args)
{
Program.GetFocusedControl().IfNotNull(ctrl =>
{
ctrl.Is(tb => tb.Copy());
}).Else(() => ActiveDocumentController.IfNotNull(notecard => notecard.NotecardView.Copy()));
};P Marc
Latest Article: C# and Ruby Classes: A Deep Dive
My BlogAh, you were my predecessor! Frankly no, I really don't.
Regards, Rob Philpott.
-
Rob Philpott wrote:
I see no benefit in the piece of code you show above.
It may just be my opinion but I find this
collection.ForEach(item =>
{
//DoStuff
});more readable than
foreach(var item in collection)
{
//DoStuff
}or
foreach(SomeDependentObject item in collection)
{
//DoStuff
}or
for(int i = 0; i < collection.Count(); i++)
{
//DoStuff
}and so on and so forth. It seems more natural when I am coding. I am given the context (the collection) and then I run some action on it for each item.
Rob Philpott wrote:
What happens if an exception is thrown during iteration?
Well then an exception happens as it would with any of the iteration styles above.
Rob Philpott wrote:
You can't tell - depends on what the extension method does.
This is my point. If your extension is complicated and verbose you are doing it wrong. It should be simple and highly intuitive of what it is doing and any exceptions that are being passed in to the extension should not be captured by the extension but show up where the exception actually occurred. This is the nature of
staticclass and has nothing to do with extensions other than that is how you implement extensions.Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
Yeah, I can accept that as a question of style and preference. For me, the implicit assumption that the extension method isn't (and shouldn't) be doing anything special at all negates the need for it, but for those who prefer the more 'fluent' style of coding I take your point.
Regards, Rob Philpott.
-
What, you don't like this code?
// Menu copy handler. If a control has focus and its an edit box, copy its text to the clipboard,
// otherwise if there's an active notecard instance, tell the notecard's view to do the copy to the clipboard.
protected void Copy(object sender, EventArgs args)
{
Program.GetFocusedControl().IfNotNull(ctrl =>
{
ctrl.Is(tb => tb.Copy());
}).Else(() => ActiveDocumentController.IfNotNull(notecard => notecard.NotecardView.Copy()));
};P Marc
Latest Article: C# and Ruby Classes: A Deep Dive
My BlogMarc, you truly are an evil man. Well done!
Reality is an illusion caused by a lack of alcohol
-
Not quite with you, but on that note, if a quantity can have a DB Null its likely going to be a reference type or Nullable<> in which you can just do (reader[i] as int?) (reader["name"] as string) etc, and that will turn you DB nulls to .net nulls for you. If you use extensions here - why not. I use them on String to give me a traditional Left and Right function. I think it's when you start involving them in the system architecture that things start to do horribly wrong.
Regards, Rob Philpott.
I am completely opposed to the AS operator. It causes more problems than it is worth. You talk about sloppy programming with extension methods, ugh, AS is worse. In fact, the AS keyword brought down an entire production system. (combined with a lazy programmer) The short story is that instead of relying on strong typing from the DB the developer used AS and converted the type to the expected type. Some DBA decided to change a database type without telling any one and a few weeks later another subsystem broke because of invalid data. Had the type been formally cast this error would have been caught immediately. I am of the camp that strong typing is important. Using conversion ... everywhere as AS encourages, only serves to disassociate developers from types (ok, this includes var) and types and the knowledge thereof is a fundamental underpinning of a stable, large system.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
-
I am completely opposed to the AS operator. It causes more problems than it is worth. You talk about sloppy programming with extension methods, ugh, AS is worse. In fact, the AS keyword brought down an entire production system. (combined with a lazy programmer) The short story is that instead of relying on strong typing from the DB the developer used AS and converted the type to the expected type. Some DBA decided to change a database type without telling any one and a few weeks later another subsystem broke because of invalid data. Had the type been formally cast this error would have been caught immediately. I am of the camp that strong typing is important. Using conversion ... everywhere as AS encourages, only serves to disassociate developers from types (ok, this includes var) and types and the knowledge thereof is a fundamental underpinning of a stable, large system.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
While I'm with you about typing (I'm of age where you were brought up to respect type safety) I don't see an issue with using 'as'. I often see a condition checking if something 'is' a type followed by an explicit cast, and I tend to replace the 'is' with an 'as' and use a null check - one less cast in effect. Actually, it's not extension methods or 'as' which is the real horror. Its 'var', but we'll leave that for another day. :)
Regards, Rob Philpott.
-
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
Not really! They are extremely useful for interfaces especially and in those cases where the code is not really in your hand.
Rob Philpott wrote:
the way to build a good system is to always, always, always keep everything as simple as you can make it.
And extension methods can be used as a way to keep the code simple and non-repetitive. In fact you nailed it well. Keep the end code simple - minimize complexities and I do not see extension methods being a hurdle rather it can be a tool to do so.
-
Rob Philpott wrote:
I see no benefit in the piece of code you show above.
It may just be my opinion but I find this
collection.ForEach(item =>
{
//DoStuff
});more readable than
foreach(var item in collection)
{
//DoStuff
}or
foreach(SomeDependentObject item in collection)
{
//DoStuff
}or
for(int i = 0; i < collection.Count(); i++)
{
//DoStuff
}and so on and so forth. It seems more natural when I am coding. I am given the context (the collection) and then I run some action on it for each item.
Rob Philpott wrote:
What happens if an exception is thrown during iteration?
Well then an exception happens as it would with any of the iteration styles above.
Rob Philpott wrote:
You can't tell - depends on what the extension method does.
This is my point. If your extension is complicated and verbose you are doing it wrong. It should be simple and highly intuitive of what it is doing and any exceptions that are being passed in to the extension should not be captured by the extension but show up where the exception actually occurred. This is the nature of
staticclass and has nothing to do with extensions other than that is how you implement extensions.Computers have been intelligent for a long time now. It just so happens that the program writers are about as effective as a room full of monkeys trying to crank out a copy of Hamlet.
-
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
-
I am completely opposed to the AS operator. It causes more problems than it is worth. You talk about sloppy programming with extension methods, ugh, AS is worse. In fact, the AS keyword brought down an entire production system. (combined with a lazy programmer) The short story is that instead of relying on strong typing from the DB the developer used AS and converted the type to the expected type. Some DBA decided to change a database type without telling any one and a few weeks later another subsystem broke because of invalid data. Had the type been formally cast this error would have been caught immediately. I am of the camp that strong typing is important. Using conversion ... everywhere as AS encourages, only serves to disassociate developers from types (ok, this includes var) and types and the knowledge thereof is a fundamental underpinning of a stable, large system.
Need custom software developed? I do custom programming based primarily on MS tools with an emphasis on C# development and consulting. "And they, since they Were not the one dead, turned to their affairs" -- Robert Frost "All users always want Excel" --Ennis Lynch
asis excellent in a situation where you don't know what you have, but you might want to do something with it. It saves you the double type check, ofif(x is MyType){
MyType myX = (MyType)x;
myX.whatever;
}instead you have
MyType myX = x as MyType;
if(myX != null){
myX.whatever;
}... which is the same length but more efficient and (imo) more obvious. When you have known types on both sides and known supposed matchups then it is just the wrong tool for the job. It's not the sledgehammer's fault it isn't good at painting windows.
-
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
I dislike them too. Linq is brilliant but it's unfortunate that it requires this mechanism. Extension methods do give you a small amount over an explicit static method, but in my opinion not enough to justify the abuse potential, which unfortunately you have suffered from.
-
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
It's just code. Deal with it.
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
You are touching on a very sore point for me; all these features encourage increasingly bad design. The saying goes "if all you have is a hammer, everything is a nail." Likewise, if what you have is "advanced" .NET 4.x, everything must use the same. Solutions which should be brain dead simple take on a monstrous complexity, especially with the developer who wants everything LINQ"ified". It seems to me that the zeal of getting things done rapidly, including various management methodologies, have trumped long term development and maintenance. My hypothesis is that the latter requires thinking, planning and patience. It more than pays off in the end, but that's not good enough to far too many developers and managers, far too many of them aren't smart enough to do it right anyway. It's simply easier to churn out code that kind of works for now and then quickly move on to another project or company, leaving the train wreck that's going to happen to someone else.
-
Sometimes I yearn for a return to .NET 2.0. The C# that came with it was a great language and now that generics were included it was essentially complete in my mind. Since then, they've been adding all sorts of dubious things to the language LINQ being the most notable but now we also have the async/await business which really is anything but the simple solution to asynchronous programming they tell us it is. Extensions methods, everyone's favourite encapsulation anti-pattern debuted with LINQ in order to make it work and some people (me) viewed them with suspicious eyes at the time but didn't really know how bad things could get. Having recently worked on a system where they have been abused to the fullest I can tell you. You start off with pretty hollow objects with very little in the way of methods, just enough to get at the data. Then, you put all your logic in extension methods, preferably in different assemblies. A sort of warped onion architecture. Now, any normal developer who goes looking for a type's methods won't find them in the type or even that assembly. A missing reference will make them disappear completely. Also, with careful planning, you can make it exceedingly hard to move that logic back where it belongs because doing so will cause all kinds of circular dependency issues. Immutable code! Shocking stuff, but if you really hate the world, don't forget the Action<> and Func<> delegates. These are useful because you can avoid passing meaningful data to methods. Instead just pass delegates everywhere (a functional programming approach I'm told). This makes it practically impossible for anyone to work out the execution flow by examining the code. Combine the two and you have one thoroughly malevolent system. People bang on about patterns all the time in software development, but if you ask me (I'm aware you didn't) the way to build a good system is to always, always, always keep everything as simple as you can make it.
Regards, Rob Philpott.
So, what you are really railing about isn't extension methods, but overly "clever" coders who turn out potentially fragile and over complicated solutions.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
So, what you are really railing about isn't extension methods, but overly "clever" coders who turn out potentially fragile and over complicated solutions.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierDing ding ding ding ding ding ding!
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein -
So, what you are really railing about isn't extension methods, but overly "clever" coders who turn out potentially fragile and over complicated solutions.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierYou could say that, but the thing is the Extension Method is a construct designed to dismantle encapsulation and whilst it may have its place here and there, otherwise it's a dangerous thing. In the wrong hands.
Regards, Rob Philpott.
-
You could say that, but the thing is the Extension Method is a construct designed to dismantle encapsulation and whilst it may have its place here and there, otherwise it's a dangerous thing. In the wrong hands.
Regards, Rob Philpott.
Rob Philpott wrote:
otherwise it's a dangerous thing. In the wrong hands.
You could do dangerous things, even back in 2.0. Ultimately, any tool in the hands of a tool can be misused and abused.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
Rob Philpott wrote:
otherwise it's a dangerous thing. In the wrong hands.
You could do dangerous things, even back in 2.0. Ultimately, any tool in the hands of a tool can be misused and abused.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierPete O'Hanlon wrote:
Ultimately, any tool in the hands of a tool can be misused and abused.
Great! :laugh:
