Read-only properties

darkelv

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.

PIEBALDconsult

Yes, but silently ignoring the value is poor style.

BadKarma

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

mav northwind

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...

CPallini

: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

Paul Conrad

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

GibbleCH

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.

Krirk

Excellent code.A guy who wrote this code is genius. :omg: :wtf:X|

My blog

Lutoslaw

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.

leppie

You need this scenario with XML deserialization.

xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 2 out now

PIEBALDconsult

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

Derek Bartram

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!?!?!??!?

PIEBALDconsult

Sure they can be abused, but I wouldn't get rid of them just because of that.

Derek Bartram

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)

GibbleCH

But properly written properties do data validation, and will modify any other values that need to be modified when that property changes.

GibbleCH

THAT'S IT! That's why I had to do something similar to this coding horror.

Derek Bartram

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?

GibbleCH

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.

leppie

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

The set accessor should then be private. However, the base class' contract may not allow that and then you're stuck.