Re: 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