Re: C# 3.0 partial methods and automatic properties

Keith Hill <[email protected]> Tue, 28 Nov 2006 18:24:05 -0700
Newsgroups gmane.comp.windows.devel.dotnet.cx
Message-ID <512BE27FB3EF0B42B619503F8ECB109B01563C8D@wcosmb05.cos.agilent.com>
> -----Original Message-----
> From: Sebastien Lorion [mailto:[email protected]]
> Sent: Wednesday, November 22, 2006 10:53 PM
> Subject: Re: C# 3.0 partial methods and automatic properties
> 
> Now for properties, none of the above applies. Except for the most simple
> getter/setter, you need to put more logic in your properties. YMMV, but
> for
> me, this happens quite a lot, if for no other reason than to raise a
> PropertyChanged event. So the usefulness of the new syntax seems marginal,
> at least in regards to the features you mention.

Yes it is limited to the simplistic get/set of a property.  However I have seen and still write plenty of simplistic get/set properties like this.

> Really, I think there are areas that need much more attention at this
> moment.

Well yeah I'm sure there are many different ideas on how to improve the language and the IDE.  And I'm certainly not saying that automatic properties is the only enhancement worthy of being added to C#.  :-)

However I do worry a bit about C# getting overly complicated and becoming the next C++.  OTOH there are plenty of things that could be done to C# to either eliminate book-keeping/line noise that are intriguing. For example, I would love to see a way to reference a type name or parameter name in code so that I could do this:

public void Foo(string s) {
  if (s == null) throw ArgumentNullException(__PARAM0);
  ...
}

or 

public string Name {
    set {
      if (_name != value) {
        _name = value;
        NotifyPropertyChanged(__MEMBERNAME);
      }
    }
}

The syntax is bogus but you get the idea.  It buys you more compile time checking.  I also find it unnerving that the new OnSerializing/ed and OnDeserializing/ed attributes can be placed on any method even though the method signature doesn't match what is required.  This will cause a runtime failure.  I would love to see the compiler catch this sort of problem.

WRT proxy classes it would be pretty cool to have some syntax like derivation (but not) that would have the compiler create a simple proxy that does all the forwarding for you except for the few methods that you need to modify e.g.:

public class Foo { 
  public string Name { get { ... } }
  public void DoIt() { ... }
  public bool CanDoIt(string s, int i) { ... }
}  

public class Bar proxies Foo {
  public void DoIt() {
    // Inject special code here and then forward
    _target.DoIt();
  }
}

Again the syntax is lame but the idea is that you shouldn't have to write all the forwarding goo yourself if the compiler do it for you.  I have read up on and played with Lisp a bit and I have to say that I like what you can do with DEFMACRO in Lisp.  The idea that anyone could create their own syntactical constructs (without having to convince the C# team to add them to the language) could be a way to prevent C# from becoming C++.  Then again it could make other people's C# code nearly impossible to read.  :-(

--
Keith

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

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