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:
That's not so much read-only as it is a "la la la I'm not listening la la la" property.
Please don't bother me... I'm hacking right now. Don't look at me like that - doesn't anybody remember what "hacking" really means? :sigh:
-
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:
Actually, I have found that sometimes you need to do that. I can't remember the exact reasoning, but a couple weeks ago I was trying to pass a readonly property to a .NET function of some sort and it would throw an error, despite, the property not being written too...the "fix" was to have an empty set...and I believe I marked it as deprecated so it threw a compile error if someone tried to write to it.
-
Actually, I have found that sometimes you need to do that. I can't remember the exact reasoning, but a couple weeks ago I was trying to pass a readonly property to a .NET function of some sort and it would throw an error, despite, the property not being written too...the "fix" was to have an empty set...and I believe I marked it as deprecated so it threw a compile error if someone tried to write to it.
The ObsoleteAttribute can't be applied to a property accessor. :( The class in question is implementing an abstract class, which specifies both get and set. I should have checked that before I posted this, but still... the set should throw a NotImplementedException or something. Failing that, the accessor should be functional.
-
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:
-
Well, if the guy who owns the interface doesn't want to remove the set from the interface, I guess you are pretty much stucked with that.
Yes, but silently ignoring the value is poor style.
-
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?
