|
First and most importantly, why do some of your capital Ts come out as capital Is?
Chris Maunder wrote: the value of a property shouldn't change “on its own"
What the heck does that mean, anyway? Does it mean other than by calling its setter? or by some dark and mysterious magical incantation?
I think what he is trying to say is that, if I instantiate a Car object, look at Car.Property,then wait a while without doing anything to the Car object, I should expect the value of Car.Property to remain unchanged.
In the example of Car.Temperature this plainly wouldn't be the case.
In a way, perhaps it would be better to use Car.GetTemperature(); as an indication that something may have changed (presumably on a separate thread, the temp is increasing).
It sort of makes sense to me, as a convenience so I can see which 'properties' of an object may be affected outside of my use of that object, but I'm buggered if I can think of a real-world case I've ever come across where this would have helped. *
With the exception throwing side, again I think he may be getting at putting volatile stuff in a method rather than a property - so the dev is 'warned' that this retrieval may cause an issue whereas, were it a property they'd be guaranteed some value.
Again, while I can potentially see value, I can't think of a case it would have been useful to me *
* In cases where really, real;ly badly written code has been before me, such rules may have helped, but when badly written code is there, chances are such rules would be broken too.
Chris Maunder wrote: Can someone smarter than me
Oops - sorry - didn't read that part. mea culpa
|
|
|
|
|
_Maxxx_ wrote: First and most importantly, why do some of your capital Ts come out as capital Is?
A very good question and I'm glad you asked.
I was typing this up while working on a few other things, then around midnight I was about to post it and my browser locked up. Totally. I'd written a fair bit over the course of my meanderings and didn't feel like retyping it, and I certainly couldn't remember off the top of my head what I'd written, so I took a screen shot of the locked up browser Just In Case.
Minutes went by and Chrome didn't unlock, and I was tired and lazy, and so I uploaded the screenshot I'd grabbed to an online OCR service that translated the image to text. I then copy and pasted the text into a new message window, fixed a few bits and pieces - mainly T's coming out as I's - and hit send. At exactly the same time the Chrome browser unlocked itself and was waiting, ready to post.
And obviously I missed some I's.
cheers
Chris Maunder
|
|
|
|
|
I was going to post "Why didn't you use Naptha[^] ?", and then remembered the "Chrome locked up part". 
That "trying to spare retyping of yours" is so nerd. I lvoe it ! 
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Entropy isn't what it used to.
|
|
|
|
|
I'd prefer:
if (liveInAlaska && someIdiotPutPlainWaterInRadiator && itIsWinter) throw exception("CrackedBlock");
to returning '20' 
In reality perhaps it depends on what type of program you are creating. If you are making diagnostic software for all modes of engine failure, a property of 'blockIsCracked' might actually make sense. But the article kinda indicates that shouldn't be a property, but a method? Too confusing - ignore the article and code whatever makes sense in the situation.
A more interesting article would have included the history of the use of properties in programming languages, and how that fit into his philosophy. Was Borland's '__property' the first extension to address this, and were they initially created to make IDEs easier to write, by giving the IDE a hook into the created executable so the IDE could display about the same thing as the final program? Or do they have a deeper history I'm unaware of?
|
|
|
|
|
Properties 'stability' convention could make sense (to me) in some contexts.
If you adopt such convention then Issue 2 is no more an issue.
Veni, vidi, vici.
|
|
|
|
|
I like Eric's thinking/teaching, and consider him, along with Skeet, Gravell, and others, including certain CP members whose names I won't mention since they can't blush, a guru's guru.
The best statements I've seen about Properties in .NET C# are in the Language Reference Manual (4th. edition with annotations) by Hejlsberg, et. al., page 43 ff., and in the comments by Liberty, Lippert, Sells, and Wagner inserted in-line as call-outs. ISBN 978-0-321-74176-9 ... see: [^].
imho, in theory, Properties are a higher-level abstraction of a Field that encapsulate behavior necessary to get/set their internal virtual backing-field, but, generally, in OOP, model attributes, rather than behavior.
Of course, in real-world practice ... well: : "In theory, theory and practice are the same. In practice, they are not." Albert Einstein 
“I speak in a poem of the ancient food of heroes: humiliation, unhappiness, discord. Those things are given to us to transform, so that we may make from the miserable circumstances of our lives things that are eternal, or aspire to be so.” Jorge Luis Borges
modified 21-May-14 3:22am.
|
|
|
|
|
BillWoodruff wrote: In theory, theory and practice are the same. In practice, they are not.
I like this.
Jeremy Falcon
|
|
|
|
|
This is our slogan in the office.
cheers
Chris Maunder
|
|
|
|
|
Interesting.
For another take look here:http://msdn.microsoft.com/en-us/library/w86s7x04.aspx[^]
Properties allow the hiding of the value in the backing store. "It is common for properties to use private fields as a backing store. The field is marked private in order to make sure that it can only be changed by calling the property." This is a very usefull way of preventing silly things from happening to the actual value and to know when the value changes because that is done through the setter. "They can take an action when data is changed, such as raising an event, or changing the value of other fields." This is another way of stating Lippert's premise "Properties should be stable" with which I agree.
About throwing exceptions the MSDN seems to disagree:
"The get accessor must end in a return or throw statement, and control cannot flow off the accessor body."
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
You're not going wrong in your thinking, you're just trying to apply black and white on a colour picture.
And since a property anyway is a wrapper for one or two methods, I feel you're free to do some interpretation of your own.
|
|
|
|
|
Jörgen Andersson wrote: You're not going wrong in your thinking, you're just trying to apply black and white on a colour picture.
In what way?
It feels like an argument for sticking to a convention without a justification for that convention. What I'm after, I guess, is the justification - or maybe as someone has stated, the history behind the thinking.
cheers
Chris Maunder
|
|
|
|
|
It was meant to be an argument in the opposite direction.
I don't see a guideline as a black and white law. But rather as 'This was the purpose, if it doesn't fit perfectly, do what makes most sense.'
|
|
|
|
|
All bullocks
A property of a car is a sort of description that describes it. The more properties you assign to a car the better it is described. Color, brand, numberoftires, but also speed, xy position, turning angle, ... are properties, because they all describe the capacity or character of that car.
A method is something that car can do (and possibly changes some properties in the process). Accelerate, turn, flipupsidedown are all examples of things that a car can do...
|
|
|
|
|
Issue 1 ignores cases where you must use a property rather than a method. Binding in WPF and serialization come to mind. More importantly, it also ignores the fact that C# properties are merely syntactic sugar provided by the compiler around method calls, which makes the whole discussion rather pointless.
Issue 2 is a guideline I wouldn't apply very rigorously. If your application uses exceptions, then your property accessors should throw exceptions as needed. If it checks return values, then is should use a recognizable error return. If the property in question can safely return a default value rather than an error value or throw an exception, then do that.
Eric does state that these are only guidelines. For the most part, I think they're useful. As always, the key is knowing which part of the blade is sharp.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: it also ignores the fact that C# properties are merely syntactic sugar provided by the compiler around method calls, which makes the whole discussion rather pointless
Sure, but if you talk about Properties outside of technical implementation details then the discussion applies.
Gary Wheeler wrote: As always, the key is knowing which part of the blade is sharp
I prefer to carry a large box of band-aids. Far more interesting.
cheers
Chris Maunder
|
|
|
|
|
I agree with you, these are at best overly prescriptive and arguably just wrong.
In my mind, a property should be a description of the state of an object. Whether that's state that's been set explicitly by previously assigning the property, implicitly by the interaction of other property setters or methods, or state that is emergent from the internal workings of the object, doesn't really matter. A property getter should be asking the question 'what is your state', whereas a method call is an instruction to do something, and any result from a function or stateful method should be a return value related to what you did, not just a reflection of object state.
Some of his points I definitely agree with: a property getter should not change the state of the object, and it should be fast. For this reason I also agree with him that you should be careful with load-on-demand properties; sometimes there's a good reason to do it, but one should seriously consider whether code that may take long enough it's worth lazy-loading its result should actually be a method call instead. Load-on-demand properties can be a lovely convenience, particularly when working with classes that cover database or file access, and I have used them quite a bit in that context, but they should always come with a health warning.
I'm definitely with you on the exception thing, though. If an object is in an invalid state and you ask it a question about its state, it's reasonable for an exception to be thrown. It's generally a good design principle to make it very difficult to get an object into an invalid state, by making property setters and state-changing methods throw if the thing you've asked them to do is invalid, but sometimes it is unavoidable (e.g. if you're covering a network dependency and the connection was dropped).
I don't have a problem with returning lists, arrays or mutable types from properties, as long as it's documented or well known among the relevant people whether it's okay to mess with them or not. As long as the class doesn't actually cause a major crash if you break its internal state assumptions, allowing the user to go down the road of 'garbage in, garbage out' by abusing your API is fine. Coders are intelligent people, we don't need to make everything idiot proof.
|
|
|
|
|
BobJanova wrote: It's generally a good design principle to make it very difficult to get an object into an invalid state, by making property setters and state-changing methods throw if the thing you've asked them to do is invalid
That's a good point: if you throw exceptions on the setter then (in theory) you will never, ever run across the situation of have a bad value from a getter. Assuming you stick to Prescription 1: A property cannot change "by itself".
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Properties should be stable: that is, the value of a property shouldn't change “on its own". Rather, changes in properties are the results of calling property setters, or some other action changing the state of the object
If by this he means properties should be read only then I can see that. Can't say I'd always do it, but I can see the reasoning.
Chris Maunder wrote: Property getters should always succeed: they should never throw an exception. Return some reasonable default value if the property cannot be logically computed right now because the object is in a bad state.
Gotta agree with this. Exceptions should not be abused and throwing on in a property getter seems way too much like overkill.
Jeremy Falcon
|
|
|
|
|
Chris Maunder wrote: What are your thoughts? Where am I going wrong in my thinking here?
You're not doing anything wrong. Which is why I stopped myself from doing a deep dive (we would have written the same thing!) and simply made the flagrant comment that his post was drivel. Seemed simpler.
Marc
|
|
|
|
|
Your efficiency, simplicity, and "do not reinvent the wheel" mentality are an inspiration to us all.
cheers
Chris Maunder
|
|
|
|
|
I agree with the premise that properties should never throw exceptions, and should instead return a reasonable default value if an error condition presents itself. If you want to throw an exception based on a property value, you should do it from the method that is using the property.
In most circumstances, an empty get/set is all that is needed. However, there are exceptions (pun - LOL). I abhor the all-or-nothing XML serialization/deserialization mechanism built into .Net, and wrote my own extension methods that can handle faulty data that returns reasonable default values for expected fields. Yeah, it takes longer to write the code, but I have a LOT more control over what's happening. As a result, pretty much all of my data-based objects contain a property called AsXElement, and a constructor overload that accepts an XElement. If there's a problem with the expected data, no exception is thrown, and the code proceeds as expected.
public class MyObject
{
public string Text { get; set; }
public XElement AsXElement
{
get
{
XElement value = new XElement("ElementName",
new XAttribute("text", this.Text));
return value;
}
set
{
if (value != null)
{
this.Text = value.GetAttribute("text", "NO DATA");
}
}
}
public MyObject(XElement value)
{
this.AsXElement = value;
}
}
Of course, different platforms require different approaches. WPF and Silverlight almost require code in property get/set, especially if they're bound to a control, and or the property's value is considered due to the use of the INotifyPropertyChanged interface.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
John Simmons / outlaw programmer wrote: pun - LOL
I don't get it.
cheers
Chris Maunder
|
|
|
|
|
Quote: I abhor the all-or-nothing XML serialization/deserialization mechanism built into .Net
I can understand that; it can be a PITA to get what you want. I use it quite a bit, and have become accustomed to it. My previous experience was using MSXML via COM in C++, so I obviously have a high tolerance for pain when it comes to XML handling.
John Simmons / outlaw programmer wrote: the property's value is considered due to the use of the INotifyPropertyChanged interface
Ah. I missed that one.
Software Zen: delete this;
|
|
|
|
|
Chris Maunder wrote: What are your thoughts?
I disagree on both points. Makes you wonder how much real code the author has written.
/ravi
|
|
|
|
|
A recently hired HR employee was on the elevator on her first day after training. A man walked on the elevator wearing flip-flops. Wanting to show her newfound authority she casually mentioned, as only H.R. can do:
"You know, Flip Flops are against company dress code"
and the man replied
"That is the benefit to owning the company"
Programming questions in the lounge.
J/k
I hate properties but I have reluctantly been using them because all of the nice generated tools and such require them. Ie, data-binding, serialization, etc. It is really a love-hate relationship but yes, generally speaking one call to get should be the same no matter what so long as set was never called.
Not to be the guy that is an apologist. But just be glad .NET DateTime isn't like the Java version. It fills the need.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
