Re: FW: C# 3.0 Automatic Properties

On Wed, 21 Nov 2007 10:04:37 +0100, Fabian Schmied <[email protected]>
wrote:

<Snip>
Hm, I still don't really follow the "adding logic down the road"
>argument. If you have a class with a public read-only field and decide
>to add some logic to the field accesses in a later version, you can
>convert it into a property, and no harm done. As Jon Skeet pointed out
>earlier, I should've thought harder before saying that changing fields
>into properties won't introduce compile-time errors; but if you use
>read-only fields, you're pretty safe. [1] You will have binary
>incompatibility, but is that an actual issue? (BTW, this is not a
>claim about public readonly fields being better or worse than
>properties. It's just about how I don't buy the argument of using
>properties in the first place to be safe for adding future logic.)

For any given circumstance you can evaluate certain principles and decide
that it doesn't apply--that's part of software development.  The fact that
you know the concequence and you've evaluated that is important.  I
think "future logic" might not be the best choice of words.  In OOD, a
goal is to abstract implementation details from interface so that
implementation details don't affect clients of that interface.  By using a
field (readonly or not) you've tied your interface directly to the fact
that you've implemented that attribute of the object as a field.  Should
you remove the field from the assembly all client assemblies that
reference that assembly must be recompiled in order to use the new
assembly.  Using a property (automatic or otherwise) instead of a field
means that potential recompilation is minimized should the underlying
implementation detail of that attribute need to change.  How likely a new
assembly can plug-and-play with existing client assemblies is a different
issue :-)

Sure, fields/properties in C# can facilitate copy-and-paste polymorphism (
in that you can write code that will work with either a field or a
property); but not polymorphism at the binary level.

Sure, to a certain extent you may couple parts of implementation details
to interface due to method return and property types; but you can at least
choose to use intrinsic or abstract types to maximize the abstraction and
reduce coupling.

<snip>
>And it would be nice to be able to mark
>the property "readonly" so that the setter could only be called in the
>constructor.

Indeed, if immutable types are to get first-class recognition in future
versions of CLR or C#, implementation details of automatic properties must
be changed to support readonly fields or else automatic properties will
not be able to support "immutable types"; at least by Joe Duffy's
definition [1].

[1] http://www.bluebytesoftware.com/blog/2007/11/11/ImmutableTypesForC.aspx

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

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