Re: Some notes on C# 3.0 (was RE: [DOTNET-CX] How to overload == for System.Double)

>string[] items = new string[] {"one", "two", "three"};
>items.Print();

Yes, you have no way in C# 2.0 to add a static method to a type you don't
have the source for (or add a method to a type at runtime...).
Effectively, that's what extension methods do for you; that's far from
sugar from a readability, discoverability, or maintainability point of
view.  It means code using an instantiation of a class will compile in one
instance and not in another--regardless that both blocks of code use the
same underlying class (simply looking at the code using the class and the
class provides no clue).  That's one of the reasons member access
specifiers do not use the form "public:", or that a "with" keyword was not
added; so code is not as context sensitive.

>
>Since the latter is just a "shortcut" for the former achieved with an
>additional compiler lookup step, this for me is syntactic sugar. (Nice
>one, actually, I've been wishing for that for a long time. The only
>thing that I think might require some rethinking is how extension
>methods get imported into the current scope.)

You're forgetting the implications on Intellisense and compatibility with
existing syntax that fell through the spec. cracks.  I get the impression
these types of things--that no one thought about--when starting "an easy
extension" is causing the lion's share of the work right now, blowing
schedule estimates out of the water.  Eric Lippert's blog is but one
example of the "oh, that's not going to be as easy as I thought"
epiphanies that have occurred in implementing the extensions in C# 3.0,
especially regarding "var" (but I won't start in on my thoughts on type-
less type-safety and "var").

"ExtensionMethods.Print(items)" is much easier to understand, doesn't
hinder discoverability, etc.

There's all sorts of "sugar" in various languages.  If this sort of thing
was a priority when C# was conceived, they would have been there from the
start.  Macros would be handy in C#, just as much as they are handy in
C++.  C# macros wouldn't have to be as type-unsafe as C++.  But, the point
is we already have C++ and C++/CLI...

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com