Properties vs public fields redux...

re: Properties vs public fields redux...

Peter Ritchie — Thu, 01 Feb 2007 21:09:02 GMT

In principle, I agree. If I haven't worked with dozens of clients working with code from hundreds of programmers where a public field invariably ends up being used externally (because it can). This, of course, leads to great discomfort when the class is refactored and that field changes type.

There's so many things to take into account when simply creating a class--most of which are ignored to simply "get it out". in .NET alone: internal or not, public or protected, sealed or not (which affects whether protected should be used), etc. ...often leading to simply accepting the defaults...

While I agree to your comments in principle, you're not suggesting design of classes "intended" to be used only internally or within the same assembly (regardless of what you tell the compiler--by possibly not including "internal") should be given the same amount of thought as an intentionally public-facing class. ...Which I'm afraid this is what some will take away, or will use in their "properties are bad" arguments (yes, there are still some out there).

re: Properties vs public fields redux...

Kevin Dente — Thu, 01 Feb 2007 22:55:47 GMT

I'd love to see the ability to declare a trivial property and have the compiler generate the backing field and getters and setters. For example:

public property string Name;

That way I get the conciseness of fields, but can substitute in a more complex implementation if needed without breaking compatibility with existing clients. This is a lot like the event keyword. Syntactic sugar, but tasty nonetheless. :)

re: Properties vs public fields redux...

ericgu — Fri, 02 Feb 2007 00:54:36 GMT

Kevin,

Back after 1.0 shipped, we spent a fair amount of design team time trying to come up with something like that. We tried a bunch of different syntactical options, but didn't come up with one that worked well, and IIRC we decided that there were other more important things to discuss. I don't know what the team thinks about that now - at that point we were trying to tread lightly in terms of adding things, and Linq negates that approach a bit...

Peter,

I do think that classes with different clients have different design goals. And I do think that external classes require more work, simply because it's so much more painful to refactor them later if you don't get it right up front.

I hadn't thought of internal classes becoming accidentally external. I'm not sure it changes my opinion, but it does provide some food for thought.

Eric.

re: Properties vs public fields redux...

Kevin Dente — Fri, 02 Feb 2007 05:12:53 GMT

Hmm. What's wrong with

public property string Name;

re: Properties vs public fields redux...

dhananjay123@hotmail.com — Fri, 02 Feb 2007 05:14:51 GMT

In principal I agree with you. But exposing member field bothers me, now suddenly you have to change your naming convention for that member field, i.e. “memberField” has to change as “MemberField”, I believe it change readers perception about code when she see the code :)

Dhananjay

re: Properties vs public fields redux...

Robin Debreuil — Fri, 02 Feb 2007 11:12:05 GMT

I agree with this one too - and I have went back and forth and I'm sure I will continue to do so. One question is, should those public fields be capitalized? It used to make refactoring easier if you later add a property. Then again with tools now it is pretty easy either way. Still it is something I debate with myself every time (usually I use lowercase).

Also, I'm not sure why they couldn't have used "public property string Name;" -- essentially the same thing is done with events. Also it could be a nice flag to the final jit code generator that the method call can be dropped for direct variable access in most cases (where now they probably have to find a usage pattern).

re: Properties vs public fields redux...

Michal Talaga — Fri, 02 Feb 2007 11:26:08 GMT

One place I see using public fields do not hurt but instead helps a lot, are the DTO (Data Transfer Objects). Making DTO use public fields no only saves you about 75% of the code, but also ensures that there will be no logic in there - which is a good thing for a DTO :-)

re: Properties vs public fields redux...

shuggy — Fri, 02 Feb 2007 12:27:29 GMT

a property which could automagically generate FooChanaged events at the same time would be nice :)

re: Properties vs public fields redux...

Gavin Greig — Fri, 02 Feb 2007 14:50:13 GMT

Kevin/Robin:

The syntax you're suggesting for automatically generating the backing code for trivial properties is exactly what C++/CLI does, and it's one of the few areas where C++/CLI has better usability than C#.

A mild annoyance is that the name of the generated field is not known, so you can't access the field directly even from within the host class, but I can't think of any reason why this would be an issue; it just doesn't chime with my preconception of where the boundaries "ought" to lie.

also incompatible at source-code level

Kristof Verbiest — Fri, 02 Feb 2007 16:11:51 GMT

Changing a public field in a property is not only binary incompatible but also at the source-code level! A field can be passed as an out- or ref- parameter while a property cannot.

So even if you ship the clients of your class together with your class, just recompiling your code may not solve the problem.

Therefore: always use properties!

I've written something about this here: http://kristofverbiest.blogspot.com/2007_02_01_kristofverbiest_archive.html

re: Properties vs public fields redux...

Dani — Fri, 02 Feb 2007 16:40:40 GMT

I cannot really agree with your point. It may be true for the moment, that you can compile the whole thing together, but it doesn't have to be like that forever. Software is changing during the time, we all know that. So it might be possible, that in future, your class will be used inside a component for an external application (or whatever)... it's not a big deal to generate properties for fields and there's no real disadvantage... so

re: Properties vs public fields redux...

Steve Cooper — Fri, 02 Feb 2007 19:56:40 GMT

This suggestion is probably an awful headache to implement, but it's more a musing on language design...

In almost all ways, the trivial property and the public field are functionally identical. The only real difference is that one has compact syntax;

public string Foo;

and one has obscenely verbose syntax;

private string foo;

public string Foo

{

get

{

return foo;

}

set

{

this.foo = value;

}

My question is, then, why not get rid of public fields at the C# level and just use the regular field syntax to generate the trivial property?

The benefits are;

- programmers don't need to worry about the field/property problem.

- programmers write significantly less code; 12 lines becomes 1.

- versioning becomes much easier, because you just can't switch from field to property.

You lose the ability to write fields, but who cares? It feels to me (though I'm sure I'm missing something) that the programmer shouldn't have to make the distinction. Why can't we leave it to the compiler?

More on properties vs fields

Eric Gunnerson's C# Compendium — Fri, 02 Feb 2007 20:10:45 GMT

Some nice comments on what I wrote . First, a non-controversial question. Robin asked whether you would

to: steve

zproxy — Fri, 02 Feb 2007 22:07:09 GMT

Well, if there would be always generated/ automatic properties - that would be a very large overhead. :)

Or maybe change syntax as such, that each native field should have a keyword "field" and without one it would be automatic property? But as the things are evolving with c#3 i do not see that happening.

re: Properties vs public fields redux...

rstrahl — Sat, 03 Feb 2007 05:07:47 GMT

The way the language works is fine I'd say - having public field and the property mechanism gives you the most flexibility and the JIT will give you inlining for performance so you don't pay for trivial property implementations. This ensures we can do the right thing.

But what would be cool if Visual Studio could help with Intellisense and the debugger display. An option to filter the property/field view would be handy. Public private (for this pointers). For example, most times I wish we could hide fields from the intellisense view. Or only show properties, only methods or only public etc.

re: Properties vs public fields redux...

Steven — Sat, 03 Feb 2007 20:42:52 GMT

C# 3.0 is getting the automatic properties that Kevin proposes. The syntax is as follows:

public string Name { get; set; }

Look here:

http://aspiring-technology.com/blogs /troym/archive/2006/11/19/53.aspx

re: Properties vs public fields redux...

Thomas Eyde — Sun, 04 Feb 2007 16:46:30 GMT

I am not too fond of the proposed syntax for the trivial property; it looks too much like an abstract property.

And why the { get; set}? If we leave out one of them, we have a useless property; one we can read, but not update. Or write to, but not read.

No. I prefer public property string Name;

re: Properties vs public fields redux...

Steven — Sun, 04 Feb 2007 17:34:34 GMT

Thomas,

I think the { get, set } is actually useful. Look at this:

public string Name { get; protected set; }

public string Name { virtual get; private set; }

Of course 'string Name { get; } would we pretty useless :-)

re: Properties vs public fields redux...

Kevin Dente — Mon, 05 Feb 2007 21:58:20 GMT

I'm with Thomas on the syntax - both for simplicity and for the nice symmetry with events.

properties vs. fields... again

jaybaz [MS] WebLog — Fri, 09 Feb 2007 00:29:54 GMT

Eric Gunnerson just posted Properties vs public fields redux... It's no secret that I agree with Eric

re: Properties vs public fields redux...

damien morton — Sat, 10 Feb 2007 05:41:07 GMT

seems like public fields should also be marked internal then?

Properties vs Public Fields redux...

DotNetKicks.com — Sat, 17 Feb 2007 04:06:00 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: Properties vs public fields redux...

Fabien Bezagu — Wed, 21 Feb 2007 11:27:35 GMT

Of course, I'd prefer not to use trivial properties but I found one reason : reflection.

In most of the framework databound controls, reflection is used to find the property matching the datamember.

For that reason, I came back to trivial properties in my domain classes...

re: Properties vs public fields redux...

Kent-Remi Gabrielsen — Tue, 27 Feb 2007 21:33:57 GMT

I just spent a couple of hours on many different blogs/forums trying to find out when to use fields and when to use properties. And, of course, without getting *The Answer*. But, Fabien's point here is right on the spot! That's exactly why I started to read about this topic(again...), and that's a very important reason to use properties and not fields. Thanks Fabien, now I am able to bind my dataclass to a gridview with two lines of code :)

Why must property?

The Pragmatic Programmer — Sun, 20 May 2007 11:50:13 GMT

Why so many people like property much than public field even though inside the property there is no other

Properties vs public fields redux...

Mighell's Blog — Sat, 18 Aug 2007 23:06:21 GMT

Properties vs public fields redux...

Mighell's Mobile Blog — Tue, 21 Aug 2007 15:07:13 GMT

Di una cosa simile, ne discutevo tempo fa con un paio di amici. L'argomento citato in questo post