C# vNext Revisited

I often rethink or have additions to my posts.  This topic of what's coming in C# vNext is definitely one of them.  I'm always looking for ways to push the envelope to see what I can get from the language.  I have to credit such people as Scott Bellware and others to look more outside of the C# bounds and look to such things as Ruby and even F# to really open my eyes to the possibilities of this language.  I'd love to see more F# features in the language as they have slowly seeped in and now pretty ubiquitous.

What I like

I enjoyed Jeremy Miller's post about what he likes about C# 3.0.  I'd definitely have to concur with a lot of those things such as his and some of my own:
  • Object Initializers
  • Lambda Expressions
  • Extension Methods
  • Anonymous types
What I'm Undecided About

So, what am I eh about?  Well, automatic properties is one of them.  Not doing much for me just yet, especially for my domain models.  Also partial methods have a particular use, but once again, it looks like a large potential for abuse.  Bart De Smet has a pretty good writeup on them though worth checking out here.  If you check out Wes Dyer's blog, he also has a good example and why you would use them.  To me, it looks like Aspect Oriented Programming in a way, but I much prefer using Windsor interception, and hopefully soon the StructureMap interception.

Do We Know Any More?

Charlie Calvert, C# Community Liason, and Mads Torgersen, C# Program Manager, wrote a post recently about the future focus of C#.  The first topic in this series is about dynamic lookup.  What dynamic lookup is, is the ability to distinguish a type at runtime instead of static compile time. 

But why is this useful?  Well, in order to interact with dynamic runtimes, this is the best way to do it.  The idea of using this for COM interop is also pretty interesting.  I've done more than my fair share in this lifetime.  Many of the things you see on PInovke.NET are ones that I either put up there or refined quite a bit, especially while using unsafe C#.

With this upcoming, could Duck Typing be far behind?  After all, it has been proposed at least for VB9, although dropped.  Of course in .NET, it's already supported on the foreach keyword as noted by Krzysztof Cwalina due to the fact you don't need to implement IEnumerable, and only need GetEnumerator().  But, will it go any further than that like Ruby?

kick it on DotNetKicks.com

3 Comments

  • Hi Matthew,

    First of all thanks for linking to my blog! Second, glad you like (most of) the new C# 3.0 features. I just wanted to drop my thoughts on the automatic properties and partial method stuff.

    Concerning automatic properties, I've seen some confusion lately because some people think it demotes properties to become public fields. Automatic properties still serve as encapsulation mechanisms for private fields but just limit the amount of typing one has to do when implementing a "simple property" that just accesses a field. But it are still real properties, meaning you can promote them to a full-fledged property at any time without breaking the external contract.

    On to partial methods. I wouldn't go as far as saying it's AOP-ish because of a variety of reasons. When looking at the generated class, it's still possible to reason about the flow of execution by having the local view on the class. That is, nothing appears out of the blue that's magically injected somewhere, in a sense that call-outs are explicit method calls to partial methods that may or may not be there depending on other parts of the partial class. Secondly, this is pure compile-time magic making all the "partial" stuff mainly useful for code generation in the light of separated extensibility (i.e. without touching the generated code as was the case in WinForms and ASP.NET pre v2.0). If one wants to achieve run-time dispatching to a method that may or may not be *overridden*, virtuals are the way to go (notice this is again something the C# language mandates to be stated explicitly, methods are non-virtual by default). To wrap up, partials are meant to be used in a code-generation environment where extensibility is key (as LINQ to SQL uses them for instance).

    As an aside I'm not really convinced about AOP in general (maybe because 95% of the samples talk about logging and such...) because run-time infrastructure (together with custom attribute metadata) can take care of lots of scenarios that AOP tackles (e.g. System.EnterpriseServices, System.ServiceModel and System.Transactions) while AOP obfuscates the code somehow through the concept of weaving (while others might argue it clarifies or simplifies things :-)).

    Definitely keep an eye on Charlie's and Mads' writings; C# vNext is going to be another great release but I guess people will be more than busy absorbing and applying the 3.0 features for the next few months.

    Thanks,
    -Bart

  • Bart,

    Thanks for taking the time to write. I actually wrote you an email the other day regarding some F# stuff.

    Yes, I see the value in automatic properties, I just haven't really had the use for them just yet. I haven't seen the true value of them, in particular, having to validate them with get and set accessors and so on.

    On the AOP front, there is a need to encapsulate cross-cutting concerns such as transactions, logging, security, etc so as to not clutter up your domain model, so it's about keeping what the domain object needs to know on how to validate, call the services, etc, but it doesn't need to put logging things, transactions and such nor should it need to be concerned with it. Take a look at NHibernate's interceptors to see good uses for them.

    Matt

  • Duck typing and dynamic objects are just a way to get around the beauty of strong types. This will "open" up the already tough world of creating good programs to even more abuse. What's more, is that how is intellisense going to overcome this, simple, it's not. So here we are regressing to huge hard copy library material to read up on how to use methods. It's a cop-out by any team that supports it to say, we'll support it, but not really. It is a direct regression a deference to VBScript and Javascript et. al. who's roots are ancient and design is poor.

Comments have been disabled for this content.