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

"Even if they are syntactical [...]"

"they" refers to extension methods. Sorry, just saw the possible confusion.

Sébastien
www.sebastienlorion.com


> -----Original Message-----
> From: Sebastien Lorion [mailto:[email protected]]
> Sent: Sunday, February 04, 2007 4:07 PM
> To: 'Discussion relating to the specifics of the C# and Managed C++
> languages'
> Subject: RE: [DOTNET-CX] 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