Re: FW: C# 3.0 Automatic Properties

> 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®  http://www.develop.com

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