FW: C# 3.0 Automatic Properties
Keith Hill <[email protected]>
| Newsgroups | gmane.comp.windows.devel.dotnet.clr |
|---|---|
| Message-ID | <85C056DDAA11E24991A029636B33BBA8920588@cos-us-mb02.cos.agilent.com> |
> -----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