Re: C# 3.0 partial methods and automatic properties

On 11/10/06, Stoyan Damov <[email protected]> wrote:
> > The issue you bring up is a VERY valid one... you get the ability to
> > change the method from the trivial stub to an actual method that does
> > something for free (from recompile of clients). This allows you to
> > standardize on the pattern of always having property accessors in a
> > wrist-friendly way.
>
> Wow, what a terrific feature! You can record a macro[1] (ctrl-shift-r)
> that does that in a few seconds.

Stoyan is being difficult again... we're not talking about an IDE
feature here. We're talking about a language enhancement that avoids
the need for this noise when it adds nothing.  I haven't seen the
proposal, but I would imagine something like

public string property Name;

which would be implemented NOW as:

private string _name;
public string Name { get { return _name; } set { _name = value; } }

Sure, that's trivial to generate, but why should I have to dedicate so
much noise to such an obvious concept?

Coupling this with Mattias' idea of the partial methods, maybe we can
get to the point where a derived (or partial pair) class could even
"decorate" the property-get of a base (order partial pair) class like
this:

public property string Name
{
   partial set
   {
      if (_name != value)
      {
         OnPropertyChanged("name", new ValueArgs( _name, value);
         this._name = value;
      }
   }
}

Now we've augmented the property setter of the class, while not
polluting or altering the original class file.

--
"We do not have the luxury of making that risky assumption that people
will not be affected by the potential change. I know this can be
frustrating for you as it is for us. Thanks for your understanding in
this matter.." --Some misguided soul at Microsoft

Marc C. Brooks
http://musingmarc.blogspot.com

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

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