|
Well, personally I say get rid of properties anyway! There is simply no point in them other than making the language more bloated and less clear.... In the good old days....
.name = public class variable, didn't run any code, just gave access.... now will it run code, or won't it!?!?!??!?
|
|
|
|
|
Sure they can be abused, but I wouldn't get rid of them just because of that.
|
|
|
|
|
Maybe, but it just seams like a lazy way of coding that means it's harder to tell what code is actually doing. Personally I feel it makes using other people's code harder (particularily badly written code where the property name is misleading)
|
|
|
|
|
But properly written properties do data validation, and will modify any other values that need to be modified when that property changes.
|
|
|
|
|
That's the problem though... the amount of people who i've seen doing things like modify data structures in property gets, is pretty high. Why leave elements of the language that can result in really hard to debug code and misconceptions?
|
|
|
|
|
But, often, if you don't modify the data of the class, when you set the property, your data may be invalid...and calling functionX at that time will result in invalid results, or errors.
|
|
|
|
|
Yes, but it leads to misconceptions about what the code does. I suppose it all comes down to good code documentation perhaps
|
|
|
|
|
...to a sufficiently motivated/determined idiot. No useful language can enforce a fixed floor for intelligence or sensibility of its (ab)user. Languages that make significant efforts in those directions, like Logo or Wirth's original Pascal, find themselves compartmentalised and marginalised safely out of the way of any Real Programmers™.
You can't effectively use language semantics to guard against process failure. The entire reasoning for practices like XP pair programming, test-driven development that requires every bit of code to be tested, and so on is precisely to guard against such ingenious stupidity.
Jeff Dickey
Seven Sigma Software and Services
Phone/SMS: +65 8333 4403
Yahoo! IM: jeff_dickey
MSN IM: jeff_dickey at hotmail.com
ICQ IM: 8053918
Skype: jeff_dickey
|
|
|
|
|
No useful language is idiot-proof...
But languages can be FOR idiots..... *see Java
|
|
|
|
|
Java, as originally conceived (J2SE, that is) is a perfectly decent language for several different problem domains, including particularly those similar to that for which it was created. The idiocy comes from two things. First, the "Java should do everything including the kitchen sink" mentality that gave us J2ME and (good working definition of "coding horror") J2EE. Secondly, the dishonest marketing commonly associated with the infinite battalions of H1B coders who have perfectly good-sounding (though mass-mimeographed) "qualifications" but couldn't solve a problem in Java (or apparently anything else) if you gave them a flashlight, a map, all the textbooks they could carry and a two-year head start. But they're the fashion, so thousands of lemmings cleverly disguised as "software-using companies" are throwing themselves of the cliff. (It's a little late to realize that you need an exit strategy when you've already been accelerating at 10 m/sec/sec for two or three minutes....)
Jeff Dickey
Seven Sigma Software and Services
Phone/SMS: +65 8333 4403
Yahoo! IM: jeff_dickey
MSN IM: jeff_dickey at hotmail.com
ICQ IM: 8053918
Skype: jeff_dickey
|
|
|
|
|
Jeff Dickey wrote: Java, as originally conceived (J2SE, that is) is a perfectly decent language for several different problem domains, including particularly those similar to that for which it was created.
Out of curiosity what domains it is better suited for?
Personally i've only ever see the advantage of Java being for mobile and cross platform applications, something I see in the second case as being of limited value.
|
|
|
|
|
I'd say small, embedded systems like set-top boxes or microwave ovens or TiVos or suchlike....close enough to the original problem domain addressed by what eventually became J2SE 1.0, without all the EE or additional-API BS-cleaverly-disguised-as-APIs. When Java was hijacked from scratching-an-itch to become the cornerstone of the One "True" Programming Religion, with hundreds of thousands of low-cost, mass-produced "proessionals", the nice, more-or-less-forward progress of software discovery and evolution took a nasty, twisted turn. For many shops controlled by Javacolytes, that 'twisted turn' has straightened out nicely. They're under a constant acceleration of ten meters per second per second...
Jeff Dickey
Seven Sigma Software and Services
Phone/SMS: +65 8333 4403
Yahoo! IM: jeff_dickey
MSN IM: jeff_dickey at hotmail.com
ICQ IM: 8053918
Skype: jeff_dickey
|
|
|
|
|
Still, its better then the following
private int m_iData;
public int Data
{
get
{
return m_iData;
}
set
{
int iOldData = m_iData;
m_iData = value;
m_iData = iOldData
}
}
codito ergo sum
|
|
|
|
|
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Excellent code.A guy who wrote this code is genius.   
|
|
|
|
|
COOL!!!!
That one is outstanding
Cheers
You have the thought that modern physics just relay on assumptions, that somehow depends on a smile of a cat, which isn’t there.( Albert Einstein)
|
|
|
|
|
You guys are so negative! Try to see the good in this approach.
Using this approach one could perform consistency checks before not saving the value...
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
|
Alternately, if at some point in time, the property was to become (or maybe was in the past) not 'readonly', applications relying on the dll wouldn't necessarily need to be recompiled to use the new dll, since the definition wouldn't change...on that item.
|
|
|
|
|
Yeach. And if some library user tried to write to a property and didn't notice that it took no effect, then after an upgrade his code could break because the old do-nothing setter would suddenly change something. 
Greetings - Gajatko
Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
|
|
|
|
|
mav.northwind wrote: Black holes are the places where God divided by 0...
Man: Hey, God, why did you make black holes?
God: I like a good BM in the morning, same as the next guy.
|
|
|
|
|
You need this scenario with XML deserialization.
|
|
|
|
|
Good point, but... Not if it's done right. I haven't done much serialization (XML or otherwise), but as I recall the class specifies which members get serialized and deserialized, so this shouldn't be a problem. You might have to override the base class' deserializer.
Or I may just be showing my ignorance. 
|
|
|
|
|
PIEBALDconsult wrote: I recall the class specifies which members get serialized and deserialized, so this shouldn't be a problem.
Sometimes you want only readonly properties in XML serialization. Unfortunately for de/serialization to work, properties need to have both a getter and a setter.
|
|
|
|
|
The set accessor should then be private. However, the base class' contract may not allow that and then you're stuck.
|
|
|
|
|
PIEBALDconsult wrote: The set accessor should then be private.
No Xml serialization (I am getting tired typing that!) will choke on that. Just try it!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
