Extension methods no good, like Lambda expressions (and an examplethat doesn't work)

R

raylopez99

The headline says it all. Great minds think alike: read the blog
below from three years ago, as endorsed by Ritchie, who coinvented
C.

BTW the below lambda expression code will not work (.Where not
recognized). I am using the 'standard' using directives using
System;using System.Collections.Generic;using System.Diagnostics;using
System.Text;

And Visual Studio 2007.

So much for the 'ease' and 'convenience' of Lambda expressions. What
a joke.

RL


int[] a = new int[] { 1, 2, 3, 3, 4, 5, 5, 6 };
var lessThan3 = a.Where(x => x < 3); //compiler error here
'not recognized'
foreach (var val in lessThan3)
{ Console.WriteLine("val: {0}", val); }


http://www.interact-sw.co.uk/iangblog/2005/09/26/extensionmethods

C# 3.0 - Extension Methods - Monday 26 September, 2005, 10:41 PM

One of the new C# 3.0 language features is 'extension methods'. The
basic idea is that the set of methods available on an instance of a
particular type is open to extension. In effect, we can add new
methods to existing types.

Some people seem to think that this is stupid because, they claim, you
can do the same thing with inheritance. However, the inheritance
approach is rife with problems. Let's look at an example.

Supposing you are dealing with some type Foo that you don't own -
maybe it's part of a 3rd party class library, so you don't get to
modify the class. Suppose that this Foo class doesn't define a method
called Bar. However, let's say you've written a method Bar that does
something useful with a Foo instance. You might decide you'd like to
be able to use the following syntax to invoke your Bar method:

void UseFoo(Foo f)
{
f.Bar();
}

As an aside, my first reaction to this is always: why exactly do you
want to do that? I tend to think that if you've written your own
method that's not a part of Foo but which does stuff to Foo, then the
code should probably reflect that. I think it's more honest, and
easier for someone else to read if your code looks like this:

void UseFoo(Foo f)
{
Bar(f);
}

However, requests for the former style seem to come up often enough
that there's no denying the fact that some people really want to do it
that way, apparently. It's not to my taste, but it takes all sorts.

Dynamic language advocates will sometimes chip in at this point to
claim that they have a 'better' solution. In Python you can
dynamically add new methods to an instance:

def UseFoo(f):
f.Bar = SomeMethod
f.Bar()

Better my arse.

This does circumvent the "I didn't create the object" and the "the
class is sealed" problems. So it's better in the sense that it gets
the job done. But it suffers from being bleedin' 'orrible, which tends
to put me off. Why's it horrible? It changes the instance that was
passed in. Was my caller expecting me to edit the set of methods
available on that instance? What if the caller was using this self
same trick to add a Bar method of their own? We just broke their code.
It seems pretty gross to me to go modifying someone else's object just
for the syntactic convenience of the method I'm writing right now.

Since almost all C# source files have a using System; declaration,
this extension method is effectively going to be available globally -
it augments the set of methods available on the base Object type.
Indeed, Peter Ritchie drew an apt analogy on the DOTNET-CX list:

"Extension methods seems to be a hack to recover from lack (or
removal, considering C++ roots) of nonmember functions"

In practice I suspect I'm being unduly nervous. I think my slightly
negative reaction is similar to the feeling I first got when I saw non-
member functions in C++ proposed as being better than member functions
in certain scenarios. "But that's not OO," I spluttered in my
(relatively) youthful idealism. These days I've learned to be
suspicious of any practice whose sole justification is that it's "more
object-oriented." If that's the only reason something has been done in
a particular way, it's probably a code smell. OO is just a toolkit,
and for certain jobs, other styles (e.g. functional programming)
sometimes offer better tools. Of course, if being "more object-
oriented" offers specific advantages in your scenario, then more power
to you, but being OO should not be an end in itself. The fact is that
not all methods belong in classes. You can see this from the way some
classes are really nothing more than namespaces in disguise. (Take a
look at System.Math for example.)
 
P

Pavel Minaev

BTW the below lambda expression code will not work (.Where not
recognized).  I am using the 'standard' using directives using
System;using System.Collections.Generic;using System.Diagnostics;using
System.Text;

There is no such thing as a "standard" using directive. You use what
you need. In your case, you've forgot to write "using System.Linq" -
Where is a method of class Enumerable, which is in that namespace. By
the way, if you were using VS2008, and if you created a project
targetting .NET 3.5, it'd use that namespace by default in all new .cs
files.
And Visual Studio 2007.

No such thing.
    "Extension methods seems to be a hack to recover from lack (or
removal, considering C++ roots) of nonmember functions"

Extension methods are not really a hack; they are merely syntactic
sugar. Arguably, the one that would not be needed in a language where
method application is uniform regardless of which argument (if any) is
the receiver - such as Dylan or CLOS - but C# inherited its syntax
from another family of OO languages.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top