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

I think one big difference between extension methods and the rest of new
features is that they have a big impact on the *public* surface of an API.
The other features are mere convenience or more powerful functional-like
capabilities. Even if they are syntactical sugar for the compiler, they are
not for the developer and the architect. This is in addition to other issues
you and others have mentionned (versioning, method name/signature
collisions, etc.).

Another thing is also the "side-effect" on intellisense. I for one do not
wish to see a bazillion methods on every single IEnumerable variable I use.
It makes the IDE slower and makes it harder to spot the one method I am
looking for. This is akin to VB.NET showing static members on instance
variables. Very annoying.

Sébastien
www.sebastienlorion.com


> -----Original Message-----
> From: Discussion relating to the specifics of the C# and Managed C++
> languages [mailto:[email protected]] On Behalf Of Bart De
> Smet [MVP]
> Sent: Sunday, February 04, 2007 3:18 PM
> To: [email protected]
> Subject: Re: [DOTNET-CX] Some notes on C# 3.0 (was RE: [DOTNET-CX] How
> to overload == for System.Double)
> 
> For what it's worth, a little overview:
> 
> * Local Type Inference is for the most part syntactical sugar (var x =
> abc;
> becomes - pseudocoded - typeof(abc) x = abc;) although it's a
> requirement to
> deal with anonymous types (needed for projections in the LINQ camp).
> * Object initializers are for 100 percent syntactical sugar and can be
> replaced with a series of setter calls or field assignments (if we do
> not
> put anonymous types in the object initialize camp).
> * Collection initializers are for 100 percent syntactical sugar and can
> be
> replaced with calls to an Add method.
> * Extension methods are 100 percent syntactical sugar and can be
> replaced
> with static method calls. It doesn't break encapsulation in any sense
> and
> isn't to be compared with C++'s friends (if anyone would think that
> way).
> For possible issues around this, take a look at
> http://community.bartdesmet.net/blogs/bart/archive/2006/12/10/C_2300_-
> 3.0-Ex
> tension-Method-Versioning-Troubles-_2D00_-Some-thoughts-and-random-
> ideas.asp
> x too (cf " might require some rethinking is how extension methods get
> imported into the current scope" - Fabian).
> * Lambda expressions are a more difficult thing as Fabian mentions
> since
> these allow (in collab with other language elements) expression tree
> generation for run-time evaluation and translation.
> * Anonymous types and automatic properties are also in the camp of
> syntax
> and could be seen as "auto-inserted compiled code snippets with
> substitutions".
> 
> I guess it all depends on personal taste; for some individuals things
> like
> lock, using and foreach in C# 1.0 could be seen as syntactical sugar
> for
> library functionality; in C# 2.0 the stuff around iterators is a far
> more
> complex piece of syntactical sugar that performs much more code
> generation
> than some might think (one keyword "yield" results in a massive amount
> of
> code generation); in C# 3.0 the expression tree stuff is on that same
> level
> while other features are much simpler substitution patterns with a
> few[C#]:few[MSIL] mapping scheme. You might argue that the way of
> thinking
> might be decisive to classify stuff in the syntactical sugar camp or
> not;
> whether you think implementation-driven (implicitly mapping on the
> runtime,
> MSIL, stack-based evaluation, processor instruction generating
> statement
> sequences, whatever is in a name) or results-driven (which LINQ syntax
> is
> clearly a good example of).
> 
> -Bart
> 
> -----Original Message-----
> From: Discussion relating to the specifics of the C# and Managed C++
> languages [mailto:[email protected]] On Behalf Of Fabian
> Schmied
> Sent: zondag 4 februari 2007 19:57
> To: [email protected]
> Subject: Re: [DOTNET-CX] Some notes on C# 3.0 (was RE: [DOTNET-CX] How
> to
> overload == for System.Double)
> 
> > For the most part, I agree.  My comments were mostly about extension
> > methods; which aren't "sugar".
> [...]
> > There's nothing in 2.0
> > that allows you to do what extension methods allow you to do in 3.0.
> 
> Hm, as I see it, extension methods actually are syntactic sugar, much
> more so than lambda expressions are, for example. (After all, lambda
> expressions enable expression trees to be generated.)
> 
> An extension method is an ordinary static method (of a class), for
> which the compiler allows you to specify the first argument before the
> method name instead of after it at the call site. Where exactly do you
> see the relationship with C++ nonmember functions?
> 
> For illustration, with the following class declaration (syntax from
> memory):
> 
> public static class ExtensionMethods {
>   public static void Print<T>(this IEnumerable<T> collection) {
>     foreach (T t in collection) {
>       Console.WriteLine(t);
>     }
>   }
> }
> 
> You can either call Print traditionally:
> 
> string[] items = new string[] {"one", "two", "three"};
> ExtensionMethods.Print(items);
> 
> Or in this new way:
> string[] items = new string[] {"one", "two", "three"};
> items.Print();
> 
> 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.)
> 
> Fabian
> 
> ===================================
> This list is hosted by DevelopMentorR  http://www.develop.com
> 
> View archives and manage your subscription(s) at
> http://discuss.develop.com
> 
> ===================================
> This list is hosted by DevelopMentor.  http://www.develop.com
> 
> View archives and manage your subscription(s) at
> http://discuss.develop.com

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

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