Read-only properties

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

[Derek Bartram]

Yes, but it leads to misconceptions about what the code does. I suppose it all comes down to good code documentation perhaps

[leppie]

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!

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

[PIEBALDconsult]

Oh, I will... I will...

[PIEBALDconsult]

I had no trouble with it.

namespace Template
{
public partial class MyClass : System.Xml.Serialization.IXmlSerializable
{
public MyClass
(
)
{
}

    public MyClass
    (
        string Name
    )
    {
        this.Name = Name ;
        
        return ;
    }

    public string
    Name
    {
        get ;
        
        **private** set ;
    }
    
    public void 
    WriteXml 
    (
        System.Xml.XmlWriter Writer
    )
    {
        System.Xml.XmlDocument doc = new System.Xml.XmlDocument() ;
        
        doc.AppendChild ( doc.CreateElement ( "MyClass" ) ) ;
        
        doc.DocumentElement.InnerText = this.Name ;
        
        doc.WriteTo ( Writer ) ;
        
        Writer.Close() ;
        
        return ;
    }

    public void 
    ReadXml 
    (
        System.Xml.XmlReader Reader 
    )
    {
        System.Xml.XmlDocument doc = new System.Xml.XmlDocument() ;
        
        doc.Load ( Reader ) ;
        
        Reader.Close() ;
        
        **this.Name = doc.DocumentElement.InnerText ;**     
   
        return ;
    }

    public System.Xml.Schema.XmlSchema
    GetSchema
    (
    )
    {
        return ( null ) ;
    }

    public override string
    ToString
    (
    )
    {
        return ( this.Name ) ;
    }
}

public partial class Template
{
    private static System.Xml.Serialization.IXmlSerializable
    Write
    (
        System.Xml.Serialization.IXmlSerializable Subject
    )
    {
        Subject.WriteXml ( System.Xml.XmlWriter.Create ( @"C:\\X.xml" ) ) ;
        
        return ( Subject ) ;
    }

    private static System.Xml.Serialization.IXmlSerializable
    Read
    (
        System.Xml.Serialization.IXmlSerializable Subject
    )
    {
        Subject.ReadXml ( System.Xml.XmlReader.Create ( @"C:\\X.xml" ) ) ;
        
        return ( Subject ) ;
    }

    \[System.STAThreadAttribute()\]
    public static int
    Main
    (
        string\[\] args
    )
    {
        int result = 0 ;

[leppie]

Implementing your own custom IXmlSerializable is cheating ;P For starters you need to use the XmlSerializer. And you code should just represent a basic C# object. Example:

using System;
using System.Xml.Serialization;
using System.IO;

public class Foo
{
public int Bar { get; private set; }
}

class Entrypoint
{
static void Main()
{
XmlSerializer ser = new XmlSerializer(typeof(Foo));

using (Stream s \= File.OpenWrite("foo.xml"))
{
  ser.Serialize(s, new Foo());
}

}
}

Fails!

<

[leppie]

This is a continuation of the sample: You might say, then use the XmlIgnore attribute, but in that case the property is never emitted, but what if you want to emit it, but you simply dont care about the result after deserializing it?

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