Read-only properties
-
I just found a bunch of properties made read-only like this (I think they're from a template):
set
{
// Do nothing
}Huh? If you want it to be read-only, make it read-only! :mad:
Still, its better then the following
private int m_iData; public int Data { get { return m_iData; } set { // store the old data // int iOldData = m_iData; m_iData = value; // reset to old data because its read-only // m_iData = iOldData } }codito ergo sum
-
I just found a bunch of properties made read-only like this (I think they're from a template):
set
{
// Do nothing
}Huh? If you want it to be read-only, make it read-only! :mad:
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... :laugh:
Regards, mav -- Black holes are the places where God divided by 0...
-
Still, its better then the following
private int m_iData; public int Data { get { return m_iData; } set { // store the old data // int iOldData = m_iData; m_iData = value; // reset to old data because its read-only // m_iData = iOldData } }codito ergo sum
:laugh:
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 -
Yes, but silently ignoring the value is poor style.
PIEBALDconsult wrote:
silently ignoring the value is poor style.
Yes, it is. I can only imagine the headache of trying to track it down on a Friday afternoon.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
-
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... :laugh:
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.
-
Still, its better then the following
private int m_iData; public int Data { get { return m_iData; } set { // store the old data // int iOldData = m_iData; m_iData = value; // reset to old data because its read-only // m_iData = iOldData } }codito ergo sum
-
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. :doh:
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.
-
I just found a bunch of properties made read-only like this (I think they're from a template):
set
{
// Do nothing
}Huh? If you want it to be read-only, make it read-only! :mad:
-
You need this scenario with XML deserialization.
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 2 out nowGood 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. :-O
-
PIEBALDconsult wrote:
silently ignoring the value is poor style.
Yes, it is. I can only imagine the headache of trying to track it down on a Friday afternoon.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
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!?!?!??!?
-
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.
-
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)
-
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)
-
You need this scenario with XML deserialization.
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 2 out now -
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?
-
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?
-
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. :-O
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.
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 2 out now -
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.
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 2 out nowThe
setaccessor should then beprivate. However, the base class' contract may not allow that and then you're stuck. -
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
-
The
setaccessor should then beprivate. However, the base class' contract may not allow that and then you're stuck.
