Sorry for being off topic (again) but I just had to comment a bit on some of the comments that were posted for the previous post.

Eyal said that this feature was also added to Delphi 2005 and that its very good for portability issues. It seems that the guys at Borland used that quite a bit to map missing functions that were in .NET and not in Delphi’s VCL which made porting a lot easier.

It’s still a dirty hack and its can and probably WILL be used in a wrongful way.

Yaniv Golan added that the Extension Methods lacks namespace support, so if I have two Extension methods named the same way (due to a reference I’ve added or some other issue) we will get unexpected behavior? Should the compiler yell about that? Will it automatically select only one?

Yaniv suggested using the syntax that includes the namespace. So if I’m taking the example from my previous post instead of having:

s.Foo();

I will have:

s.MyExtension.Foo();

After all what will happen if someone adds some extension method and in a future version of the BCL (Basic Class Library) someone adds an extension method with a similar name?

Barry Kelly said that Extension methods were added because “It is absolutely required in order to extend IEnumerable to support the new query methods such as Max, Select etc.“.

Perhaps I don’t have the exact vision that Anders Hejlsberg has for C#, and you can call me old school if you wish, but I think that this whole LINQ thing could have been implemented as a certain type of framework.

Yes ADO (ActiveX Data Objects) wasn’t part of the language but most Visual Basic 6 users were able to use it with little to no effort. So it wasn’t part of the language and the compiler didn’t understand a thing about it. So what?!

As far as I know (and people, please correct me if I’m wrong) the compiler can only check the syntax correctness of the statement but can’t perform any other checks at compile time.
Yes, this syntrax might be a bit more intuitive but I’m quite sure this could have been made without brutally hacking the compiler and adding these features.

What’s wrong with a syntax like:

int[] numbers = { 2,2,2,4,5 };
int count = LINQ.Count(LINQ.Distinct(numbers));

I also wonder what happend to the whole XQuery idea? I remember Microsoft releasing an XQuery implementation? XQuery is a language that can be used not only for XML querying but to query and intersect information from various places much like LINQ’s features.

I might be missing the vision of marrying data access with the language itself, but I really don’t think this is the MOST necessary feature that will boost productivity and will ascend to a level of a killer feature.

  • Len Holgate

    I’ve suggested here that a potential solution to the likely misuse of this feature is to force classes to “opt in” to use it by specifying that the class is “extensible” in much the same way that classes can “opt out” of extension via inheritance by specifying that they are sealed. Most classes wouldn’t need to opt in, probably only data stores and collections. I think this would limit the likely damage from misuse.

    I’m always dubious of language changes that are “essential” for the design of a new library. After all, most of us design pretty well without being able to change the language when it doesn’t fit with out current favorite design 😉 When you know that you can change the syntax of the underlying language perhaps you don’t try quite as hard as you could to do it some other way…