Automatic vs Explicit Properties

re: Automatic vs Explicit Properties

Patrick Dewane — Wed, 14 Jan 2009 21:33:56 GMT

Perhaps the user was concerned with the unnecessary stack push needed when calling a property, when all the user really wants is the private backing field. I blogged about this a while back, and while I like the idea of automatic properties I'm not sure the savings in keystrokes is worth the stack push. Am I wrong about this?

re: Automatic vs Explicit Properties

JD — Thu, 15 Jan 2009 01:00:07 GMT

Patrick: I'd expect the jitter to inline the property access, so I'd be surprised if you actually end up incurring any runtime overhead (unless optimizations are disabled of course).

re: Automatic vs Explicit Properties

SealedSun — Thu, 15 Jan 2009 05:42:19 GMT

What I don't like about automatic properties is the lack of the readonly modifier. I really am a fan of immutable objects and would like the compiler to enforce the write-once semantics.

re: Automatic vs Explicit Properties

Sebastien Lorion — Thu, 15 Jan 2009 05:59:33 GMT

Another reason for using "explicit" properties is to change the backing store (say a dictionary, the ViewState, etc.). In that case, no change is required also.

re: Automatic vs Explicit Properties

Renaud Bédard — Thu, 15 Jan 2009 06:11:33 GMT

One scenario I often encounter (and I read on programming blogs that I'm not the only one) is that I need an event raised when a property value is changed, whether it be from the exterior or interior. Now it's impossible to do this with implicit properties, but I sure wish there would be an "eventful" modifier on them. I find implicit properties a lot cleaner and more often than not that event is the only thing I add.

re: Automatic vs Explicit Properties

Petar Repac — Thu, 15 Jan 2009 10:53:08 GMT

I think that the issue here is not tightly bound to automatic property. It answers the question "from within my class should I use private fields directly or go through the property".

Automatic properties force us to go the second way. And it sometimes it's not the right way to go.

Very good post. Thanks Eric.

re: Automatic vs Explicit Properties

Matt — Thu, 15 Jan 2009 11:14:44 GMT

I too miss the the readonly ability, However the only way the semantics of this would correspond with normal readonly fields is for the set to only be legit *within* the constructor. As such object construction syntax would not be permitted (since they happen post construction). Given this this doesn't help much for the effort.

What I really want is immutable declarations on classes/structs...

re: Automatic vs Explicit Properties

Matt — Thu, 15 Jan 2009 11:33:59 GMT

"And it sometimes it's not the right way to go."

Why? can you come up with an example of why you wouldn't want to?

There is only one I know of (which is fixed in 3.5 SP1 32bit) which is that if the property is a non primitive struct the get/set will not be inlined. I would think for most that's a boundary case and the only reason to ever change it is if you profiling suggests it is required.

Periodic Digest of Interesting Stuff

Steve Strong's Blog — Thu, 15 Jan 2009 12:47:11 GMT

Periodic Digest of Interesting Stuff

re: Automatic vs Explicit Properties

Petar Repac — Thu, 15 Jan 2009 12:56:41 GMT

Matt, I was talking about using the "property access" within the class as not the right way to go. The example has been given by Eric in the post. It's when the semantics of accessing the internal object's state is different when we access it from the outside as opposed when we assess it from the inside.

re: Automatic vs Explicit Properties

[ICR] — Thu, 15 Jan 2009 13:18:18 GMT

"I'm not sure the savings in keystrokes is worth the stack push"

If you run it in Release mode without a debugger attatched when you start the program (you can attatch one after) it will inline trivial properties.

re: Automatic vs Explicit Properties

Stephen — Thu, 15 Jan 2009 15:57:39 GMT

At first I thought automatic properties were a neat idea, in reality I find I hardly ever use them.. the only time I can usually rationalize their use is when I have 'business objects', but then I tend to find that having property change notifications is useful (or required), and then I might as well throw the automatic properties away, it doesn't really cause any problems.. I just think that automatic properties tend to be more useful when you are conceptualizing in code.

re: Automatic vs Explicit Properties

Joe — Thu, 15 Jan 2009 22:48:11 GMT

Am I the only one that has wanted an access modifier that was the exact opposite of "private", that allowed you to define methods that could only be used from external classes? Probably. :)

But that came up when dealing with this case. The class should have only used the private backing field, and never the public property

re: Automatic vs Explicit Properties

Kevin Westhead — Fri, 16 Jan 2009 03:45:04 GMT

I agree with the comments about auto-implemented properties needing a better way to express read-only properties. I blogged about why I don't like the "private set" approach to simulating a read-only property.

re: Automatic vs Explicit Properties

Stephen — Fri, 16 Jan 2009 23:39:58 GMT

Yea one of the things I didn't like about private set was the fact that you don't get told the property is read-only.. you get told you don't have access to it.. erugh.

re: Automatic vs Explicit Properties

TheCPUWizard — Fri, 29 May 2009 18:13:16 GMT

I *NEVER* access the backing field outside of the propery. EVER.

If I need different semantics, then I use different properties:

Money Balance { get; set; }

Money SecureBalance { get { if (...) throw; return Balance }