|
HAPPY BIRTHDAY MIKE!
Software Zen: delete this;
|
|
|
|
|
Thanks y'all for birthday wishes, 65 today and going fishing.
Along with Antimatter and Dark Matter they've discovered the existence of Doesn't Matter which appears to have no effect on the universe whatsoever!
Rich Tennant 5th Wave
|
|
|
|
|
Give a man a fish and he'll eat for a day.
Teach a man to fish and he's gone all weekend!
|
|
|
|
|
Give a woman a fish, and you'll sleep on the couch again.
|
|
|
|
|
Happy One-More-Year-Closer-To-Retirement!
|
|
|
|
|
|
Happy birthday, youngster! 
/ravi
|
|
|
|
|
Thanks Ravi it's been eventful.
Along with Antimatter and Dark Matter they've discovered the existence of Doesn't Matter which appears to have no effect on the universe whatsoever!
Rich Tennant 5th Wave
|
|
|
|
|
Happy Birthday Mike
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
Dear all,I had written a webserver use HttpListener, when i respon data to client, some time it show error: System.Net.HttpListenerException (0x80004005): The specified network name is no longer available
at System.Net.HttpResponseStream.Write(Byte[] buffer, Int32 offset, Int32 size)
Can anyone give me a help or suggestion?
Thanks very much.
|
|
|
|
|
senlin110 wrote: Can anyone give me a help or suggestion?
I suggest you use the link above and post your question in the Quick Answers section.
|
|
|
|
|
senlin110 wrote: Can anyone give me a help or suggestion?
Yes: learn to read.
"Technical discussions are welcome, but if you need specific help please use the programming forums."
Try here: http://www.codeproject.com/Questions/ask.aspx[^]
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
you should post in Question / Answer.
Life is all about share and care...
public class Life : ICareable,IShareable
{
// implements yours...
}
|
|
|
|
|
senlin110 wrote: Can anyone give me a help or suggestion?
SELECT is still not broken.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I read the article from the Insider[^] about properties and methods and the author states
Issue 1.
Quote: 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
So the mass of a car can be a property since it doesn't change, but the total mass, including fuel, can't be since fuel is burned and so changes.
A specific example is DateIime.Now which should not be a property because it changes and really ought to have been a method GetCurrentDateIime.
I'm assuming the author means we should have a IimeZone object with a Now property, with Now being updated explicitly through some process such as TimeZone.Now = DateTime.GetCurrentDateIime(). Which seems a great way to spend your spare CPU cycles.
Can someone smarter than me please explain why properties should only be things that can't change? To stretch the car analogy if you have an Engine and Radiator object with the Radiator having a property Temperature then I can accept the argument that the water doesn't get hotter on its own. You'd have something like
class Engine
{
void RunEngine()
{
...
water.Temperature += Degrees(10);
...
}
}
But what of the Car object that aggregates an Engine and a Radiator object? The car's EngineIemperature property (which is a façade for the Engine.Temperature property) is going to change "on its own" sorta kinda. It'll change due to changes passed on by internal objects.
Issue 2.
The author states
Quote: 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.
Doesn't this fly in the face of the "use exceptions not error codes" argument. I understand we're not talking about returning an error code - we're talking about completely hiding the fact that there was an error and simply returning a value that is "reasonable". In fact aren't we simply bypassing the entire exception-vs-errorcode debate and simply ignore it?
Sure - you can return null values for properties that don't currently exist on an object, but what if a property is expansive to retrieve and a timeout / resource error / whatever happens while querying the property. Surely something should be mentioned to the caller that may the value they have is a little dodgy and maybe they should try again later?
All in all this seems like a discussion on theoretical guidelines that ignore important realities.
What are your thoughts? Where am I going wrong in my thinking here?
cheers
Chris Maunder
|
|
|
|
|
I think these are like the pirate code: they are more like... guidelines!
Feel free to ignore them! 
My guidelines are very simple:
- if you can get and set it and it and it's inexpensive: then it's a property
- if it looks good as a (still inexpensive) property: then it's a property!
|
|
|
|
|
Chris Maunder wrote: a discussion on theoretical guidelines that ignore important re
I agree.
Seriously, a developer has to use his own brain and not just blindly follow "rules" made up by others.
"But his unbiased opinion, his mature judgment, his enlightened conscience, he ought not to sacrifice to you, to any man, or to any set of men living. ... Your representative owes you, not his industry only, but his judgment; and he betrays, instead of serving you, if he sacrifices it to your opinion." -- Edmund Burke, 1774
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Chris Maunder wrote: All in all this seems like a discussion on theoretical guidelines that ignore important realities.
You are way too kind! I thought it was more opinionated than based on any practical application. I closed the page before getting half-way through it and then I look here and find I'm not alone. There is obviously a concern over performance but after that, my only question is, "Did it work?"
<sig notetoself="think of a better signature">
<first>Jim</first> <last>Meadors</last>
</sig>
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
