Read-only properties
-
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 nowWhy write a class in a particular (bad) way just to bypass a flaw in some other brain-dead class? Dealing with a class that someone else wrote which doesn't implement the desired serialization is another matter entirely, but when you're writing the class you have control. If you're writing a class intending it to be serialized, then it should be marked with SerializableAttribute and implement ISerializable and/or IXmlSerializable as appropriate. "Use the right tool for the right job." -- Scotty, et al
-
That's just crazy talk; if the class doesn't implement IXmlSerializable then clearly it can't be serialized to XML, so don't try. This is like trying to use a DataAdapter on a query with a join or a view or something and then complaining that .Update won't work. And as I said, "Not if it's done right"; I done it right, you didn't. I win, neener neener neener! :laugh:
PIEBALDconsult wrote:
That's just crazy talk; if the class doesn't implement IXmlSerializable then clearly it can't be serialized to XML, so don't try.
The way I showed you is exactly how web services does it. [update] I think, it's 5:30 am, I just woke for a smoke, not thinking really [update]
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 2 out nowmodified on Saturday, March 22, 2008 11:38 PM
-
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 missed public virtual Property { get {...} set {..}}
-
You missed public virtual Property { get {...} set {..}}
Well that is what I was alluding to when I said: " The set accessor should then be private. However, the base class' contract may not allow that and then you're stuck. " (In a different branch.) However in your example, the derived class should at least call
base.Property. If the base class isabstractthen you're stuck (but an exception should be thrown or something!). However, I argue that an abstract class should probably not specify that asetis required, which may be a whole new topic. -
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
COOL!!!! That one is outstanding :laugh: 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)
-
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?
...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
-
...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
-
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
-
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.
-
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