Re: C# 3.0 partial methods and automatic properties

> some light on this new feature? Is it finally possible to implement
> the same method in different parts of a partial class, having these
> implementations being merged into one? Or is it something different?

No idea on this one... I'm interested too...

> After all, an auto-generated property behaves pretty much the
> same as a public field, with the only advantage being that you can
> choose to make it more complex at a later time without having to
> recompile client code. Is that really so important? Am I missing
> something?

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.

The OTHER thing this gains you is that much of the DataBinding code
(and such) all over the framework will only allow you to bind to
properties, not fields. This means that they can always count on there
being a Get/Set method. I think having public fields was an error in
C# 1.0...  and I said so at the time... now many years later doing
tons of reflection and dynamic code, I wish they hadn't made the
FieldInfo so functional :)
>
> Regards,
> Fabian
>
> ===================================
> This list is hosted by DevelopMentor(r)  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com
>


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