Re: FW: C# 3.0 Automatic Properties

I agree with Keith's arguments.

One slight correction though.  I believe he meant const fields rather than
readonly.  There is a slight difference between the two.  Const fields are
baked into the client since they are known at compile time.  However,
readonly fields are not since they are not known at compile time.  For
example, a constructor can set a readonly field to some dynamic value at
instance construction time.  But the argument he makes below regarding const
fields being baked in at compile time is a very valid one.

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.

        -Trey

------------------------------------------
Author "Accelerated C# 2008" and Accelerated C# 2005"
Apress

> -----Original Message-----
> From: Discussion of development on the .NET platform using
> any managed language [mailto:[email protected]]
> On Behalf Of Keith Hill
> Sent: Tuesday, November 20, 2007 3:54 PM
> To: [email protected]
> Subject: [DOTNET-CLR] FW: C# 3.0 Automatic Properties
>
> > -----Original Message-----
> > From: Fabian Schmied [mailto:[email protected]]
> > Sent: Wednesday, November 14, 2007 1:22 AM
> > Subject: Re: C# 3.0 Automatic Properties Encapsulation is a
> nice word,
> > but IMO in many, many cases (like utility structs) public readonly
> > fields do the job very well. I've yet to hear a convincing
> reason to
> > prefer properties over public readonly fields when both of
> them would
> > be applicable.
>
> I have to disagree.  IMO it is a bad idea to expose public
> fields (even readonly) unless you are talking about a true
> cosmological constant like Pi or E.  The reason is that
> public field values get baked (compiled) into your client's
> code.  Once a client has compiled against your type, it will
> never ask for that public field value again until you
> recompile.  So if you decide to change the value well then
> all your clients will have to recompile.  And as far as
> performance is concerned most trivial property getters are
> inlined.  Furthermore, you may decide that you need logic in
> the retrieval of the field's value - oops can't do that.
> Non-readonly fields are worse since they can never be thread
> safe (unless there is a field sync attribute I don't know about).
>
> BTW for the folks objecting to the compiler syntactic sugar
> known as automatic properties, how is this that different
> than what the compiler does for you when you use the event keyword?
>
> --
> Keith
>
> ===================================
> This list is hosted by DevelopMentor.  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>
>

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

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