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

> 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.

Well, I guess it's not that clearly defined what "syntactic sugar"
actually is. Extension methods don't go so far as some other
object-oriented languages go (SELF; Smalltalk too, I guess?): they
cannot override an existing instance method, they cannot be added at
runtime, etc. They are just a different syntax for calling (certain)
static methods. So to me, that would classify them as "syntactic
sugar", or at least a special syntactic shortcut for something that
could also be done differently.

Syntactic sugar can of course have effects on readability,
discoverability, etc, both positive and negative. The "using"
statement definitely has positive effects on readability and
maintainability, IMO, despite it only being "syntactic sugar" for a
try/finally block.

The question of exactly how good or bad the effects of extension
methods are - I don't know, yet. I haven't done a project with C# 3.0
yet, I haven't read any real code yet, apart from some samples, and:
C# 3.0 hasn't really been finished yet.

But I do think that extension methods can improve readability and
other code quality features. To me, "collection.Print()" is far more
object-oriented (I'm sending the collection the message to print
itself) and readable than "Utilities.Print(collection)". They are also
a really interesting solution to the problem of whether interfaces
should be small and easy to implement (consider: IEnumerable<T> or the
non-generic ICollection) or large and easy to use (consider
IDictionary<TKey,TValue>).

And, as I've already said, I also think that maybe it should be made
more explicit what extension methods influence a piece of code.
(Bart's blog item [1], which he referred to in his other message, has
some ideas on that.)

> 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.

Well, code is already context sensitive in a similar manner as with
extension methods if you consider the "using" declaration for
importing a namespace's classes into the current scope. If you import
a namespace with "using", you can use its types with their short
names; otherwise, you need to explicitly use the full ones.

That's actually quite similar to how extension methods make code
context sensitive: If you import them, you can call them directly on
the instance; otherwise, you need to explicitly name their type. Of
course, what I don't like is that you automatically get all the
extension methods from a namespace (at least from the assemblies you
reference) when you import it.

> You're forgetting the implications on Intellisense and compatibility with
> existing syntax that fell through the spec. cracks.

Yes, it definitely has an impact on intellisense, and on the rest of
the IDE as well. I'd like a clear visual distinction of extension
methods in both intellisense and in the IDE, for example. Maybe the
code editor should highlight extension methods a different color. When
pressing F12, I want the IDE to correctly take me to the class
declaring the extension method, and so on.

What compatibility problems with existing syntax are you referring to?
Since extension methods have lowest possible precedence, they
shouldn't affect any existing (compiling) code, right?

>  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.

Well, I don't know whether extension methods were considered an "easy
extension"; I guess additions to programming languages are seldom
"easy" :)

> 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.

Well, the question is whether C# is allowed to evolve. I mean, one
can't just assume that they got everything the ideal way in the first
place, can one?

Fabian

[1] http://community.bartdesmet.net/blogs/bart/archive/2006/12/10/C_2300_-3.0-Extension-Method-Versioning-Troubles-_2D00_-Some-thoughts-and-random-ideas.aspx

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

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