C# 4: Immutable type initialization

Readonly locals? | keyongtech

Readonly locals? | keyongtech — Sun, 18 Jan 2009 16:46:53 GMT

Pingback from Readonly locals? | keyongtech

re: C# 4: Immutable type initialization

VekiPeki — Thu, 04 Sep 2008 10:35:06 GMT

@Jon: "I'm pretty ignorant about XML serialization" -- I find this hard to believe :)

But anyway I found a way to do it at the end, so I will just post a quick answer if anyone comes across the same problem:

I ended up using Reflection to change the state of the object inside the implementation of IXmlSerializable.ReadXml, while leaving the private fields readonly.

I made a new ImmutableObject class as a base class for other immutable classes which I would like to make xml-serializable, so all the messing with Reflection is confined to this base class only.

Thanks anyway - you actually answered it, I came across one of your posts: bytes.com/.../post2178883-17.html

Best regards,

Veki

re: C# 4: Immutable type initialization

skeet — Tue, 02 Sep 2008 06:09:47 GMT

@Veki: I'm afraid I don't know. I don't even know if it's possible. I'm pretty ignorant about XML serialization, I'm afraid :(

Jon

re: C# 4: Immutable type initialization

VekiPeki — Tue, 02 Sep 2008 05:44:40 GMT

Hi!

I've posted this same question to a couple of other places but was unable to find the answer:

I've been looking around for a simple example of the "right way" to implement immutable object xml serialization/deserialization.

Since IXmlSerializable.ReadXml(System.Xml.XmlReader reader) requires the object inner state to be changed, I have to make private fields writable, which I would like to avoid. I've tried googling it but was unable to find the answer I was looking for.

Thanks a lot,

Veki

Lessons learned from Protocol Buffers, part 1: messages, builders and immutability

Jon Skeet: Coding Blog — Wed, 20 Aug 2008 16:31:56 GMT

My port of the Protocol Buffers project has proved pretty interesting. I thought I'd share some of

re: C# 4: Immutable type initialization

Keith J. Farmer — Tue, 20 May 2008 21:12:37 GMT

Obviously, this has had a lot of thought on many fronts. I'd like to see readonly properties in general, not just autoprops. This is a little more complex, since it potentially means that readonly fields *could* be referred to outside the constructor, but only in other readonly blocks.

With these, and getter/setter args instead of (or in addition to) property-scoped fields, I'd be happy to do away with (non-property-scoped) fields altogether.

public readonly int IntValue

{

get;

set(field)

{

if (field < 0) throw new ArgumentOutOfRangeException();

field = value;

}

re: C# 4: Immutable type initialization

Andrew Shapira — Wed, 07 May 2008 11:26:31 GMT

Here's some more discussion of immutable objects in C#: onezero.org

Pages tagged "immutable"

Pages tagged "immutable" — Mon, 31 Mar 2008 11:15:16 GMT

Pingback from Pages tagged "immutable"

re: C# 4: Immutable type initialization

skeet — Wed, 19 Mar 2008 10:13:11 GMT

Oh it's definitely worth being cautious of *any* new feature in a language - and I can certainly see how some of Java's features haven't been as carefully thought out as they might have been.

The good thing about just blogging on these matters is that I know my blog is read by much smarter people than myself (or at the very least people with much more experience of language design than I have). I can make straw man proposals which may have *some* good points along with distinct downsides. I'm relying on the professionals to polish the good stuff while avoiding the problems :)

re: C# 4: Immutable type initialization

Ben — Wed, 19 Mar 2008 10:03:29 GMT

Sorry, ignore the type system aspect. I had a very specific design in mind to cover the general case and I shouldn't have brought it up so vaguely on a blog.

I agree that what you're asking is the ideal, but my point was you don't sacrafice much by working with what you have smartly. And from the Java world, everyone I meet seems to have their own language extension proposal, so perhaps I'm a bit overly cautious!

Extensive deep cloning is horrible, but very careful usages is fine. In both cases you'll get validation and a runtime error in the same execution flow. If the framework that digest it automatically validates the configuration, its equivilant to the IOC approach with huge constructors as the bean is instantiated when its specifically required. So that's my reasoning! :)

You're idea would be a nice asset, but having seen the horrific abuses proposed for cramming garbage into Java's type system I'm overly cautious of any type system propsals.

re: C# 4: Immutable type initialization

skeet — Tue, 18 Mar 2008 10:37:05 GMT

Ben: "The cases I have had them are configuration, where I use setters to avoid the ugliness of a long constructor."

Exactly - that's precisely why I've mentioned IoC containers a couple of times. I don't like deep cloning and then explicit validation in terms of design - it would be nicer for the validation to happen automatically on construction, and for there to be no need to do cloning at all.

I don't see explicit validation and cloning as good design - I see it as a way of getting round the lack of simple initialization of immutable types.

Not sure what you mean about the xml-style type system and supportive framework, but even if there's a lot of generated code for production stuff, I think it's important to be able to easily construct objects manually for unit tests and the like.

re: C# 4: Immutable type initialization

Ben — Tue, 18 Mar 2008 09:32:22 GMT

Its pretty rare that I have an immutable object with a large number of attributed. If you have any class with a lot, you probably need to revisit the design.

The cases I have had them are configuration, where I use setters to avoid the ugliness of a long constructor. Example - a distributed master/worker framework, where configuration is set before the task's execution. In these cases, I've cloned the object (deep copy) so that the client can't modify it. I'll also add a validation method before execution starts.

If you're concern is objects like a user's profile, as in your example, it really isn't a big deal once you have an xml-style type system and supportive framework. Its all generated code, such that the mess of large constructors isn't seen.

Anyway, the point is that good design resolves all these issues. Everyone seems to want to put their 'touch' on their favorite language and add something new. If you focus on a clean design even the most complex tasks really becomes simple and elegant. At that point, you don't need the compiler or language to do anything but get faster.

Dew Drop - March 17, 2008 | Alvin Ashcraft's Morning Dew

Dew Drop - March 17, 2008 | Alvin Ashcraft's Morning Dew — Mon, 17 Mar 2008 12:07:31 GMT

Pingback from Dew Drop - March 17, 2008 | Alvin Ashcraft's Morning Dew

Reflective Perspective - Chris Alcock » The Morning Brew #54

Reflective Perspective - Chris Alcock » The Morning Brew #54 — Mon, 17 Mar 2008 08:24:08 GMT

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #54

re: C# 4: Immutable type initialization

skeet — Sun, 16 Mar 2008 19:11:18 GMT

Restricting the defaults that far would severely limit the usefulness of the feature, IMO. I'm sure it wouldn't be that hard to include defaults in a useful manner.

re: C# 4: Immutable type initialization

Jonathan Allen — Sun, 16 Mar 2008 17:00:10 GMT

Why not use optional parameters and require the defaults to be Null/0. That way their is no default to speak of.

You could even go one step further and require all optional types to be Reference or Nullable<T>.

re: C# 4: Immutable type initialization

Marc Gravell — Sun, 16 Mar 2008 10:29:49 GMT

Re defaults... perhaps simply insist that *all* initonly values must be provided in the initializer? A half-formed immutable object isn't that much use... I think this would address the 90% case... for the remaining case when there are scenarios to use different sets of options, then this "initonly" isn't suitable, and the author must write ctors for each valid combination.

But a simple "you can set all, by name, w/o writing a ctor" would go a long way...

In fact, in this case the *final* ctors probably *replace* the existing ones - i.e. Foo(string) becomes Foo(string,[...]), but there is no Foo(string).

Of course, at this point all we've done is provide "pass by name" to ctors, and an auto-generated ctor... not sure...

re: C# 4: Immutable type initialization

skeet — Sun, 16 Mar 2008 10:02:56 GMT

Marc, I was thinking about that. The difference would basically be in terms of named vs positional arguments. The defaults issue goes back to "provided by the caller" or "provided by the callee" issue - the same reason Anders didn't want optional parameters in the first place. If the value could be moved to the callee somehow, with the caller indicating which values they're really providing, that would be an alternative approach.

re: C# 4: Immutable type initialization

Marc Gravell — Sun, 16 Mar 2008 09:51:28 GMT

Another thought; one of the outstnadning issues was default values. If that can be solved, what difference between a compiler-generated init class, and a compiler-generated constructor? i.e. those members marked "initonly" actually become an additional (single) ctor, with the defaults being provided by the compiler. For every standard public/protected ctor(foo,bar), there might be an additional ctor(foo,bar,[the various initonly members)...

At the language level, these additional ctors could perhaps be attributed and available by member-name via initializers - but from other (unaware) languauges could be used as the "lots of parameters" ctor.

C# 4 et automatic properties

Matthieu MEZIL — Sun, 16 Mar 2008 08:07:20 GMT

Jon Skeet présente dans son dernier billet une future nouveauté de C#4 : public string Line1 { get; initonly