Re: FW: C# 3.0 Automatic Properties

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


You are right in that for 90+% of projects this is probably not too
much of a concern (perhaps a touch wasteful, especially in say a smart
client app, but not a major concern)

Cheers,

Greg
On Nov 21, 2007 1:04 AM, Fabian Schmied <[email protected]> wrote:
> > But the point he mentions about adding logic down the road is a great one
> > and essentially what I meant when I posed my argument of how automatic
> > properties foster stronger encapsulation than readonly public fields with
> > relatively little extra typing.
>
> 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.)
>
> I do like Jon's point about how the details of your state management
> are hidden when you have a property rather than a field, that's
> actually a very nice argument. But my initial claim was about things
> like utility structs - simple, immutable value holders, like a Tuple
> data type or an immutable Point struct. I don't really see a problem
> with exposing the fact that the type is a simple value holder. Do you
> see any value in the encapsulation of the fields of such types?
>
> Originally, about a year ago, I thought that automatic properties
> could only have the same visibility for both setters and getters,
> which would have made them pretty much useless for me. Since that is
> not true,  I've found them to be quite useful in the meantime. So I
> don't hold up last year's argument that automatic properties are
> little more useful than public fields, but I still don't like
> generalizing claims about how public fields are always a bad idea :)
>
> About improving automatic properties - it would be nice if there was a
> way to apply attributes (especially the NonSerialized attribute) to
> the generated field. (This is possible for the fields generated by the
> event keyword, by the way.) And it would be nice to be able to mark
> the property "readonly" so that the setter could only be called in the
> constructor.
>
> Fabian
>
> [1] BTW, I once read, I think it was on Brad Abrams' blog, that this
> "changing fields into properties" scenario was the reason why public
> fields follow the same naming convention as public properties in the
> .NET framework naming guidelines. Although I don't think it was
> actually encouraged to expose public fields that might later change
> into properties.
>
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com
>



--
Studying for the Turing test

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

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