Creating an immutable value object in C# - Part V - Using a library

Geek Lectures - Things geeks should know about » Blog Archive » Creating an immutable value object in C# - Part V - Using a library

Fri, 11 Jan 2008 22:25:38 GMT

PingBack from http://geeklectures.info/2008/01/11/creating-an-immutable-value-object-in-c-part-v-using-a-library/

Immutability in C#

Community Blogs — Thu, 17 Jan 2008 02:44:56 GMT

For some reason, there's been a lot of buzz lately around immutability in C#. If you're interested in

Community Convergence XXXIX

Charlie Calvert's Community Blog — Mon, 21 Jan 2008 09:45:40 GMT

Welcome to the XXXIX issue of Community Convergence. The big news this week is that Microsoft has begun

re: Creating an immutable value object in C# - Part V - Using a library

mg — Sat, 02 Feb 2008 04:06:12 GMT

Nice work!

One question about "stealing" the base class - what about introducing another layer of abstraction and instead of declaring your type like this:

public class DateSpan: Record<DateTime, DateTime, bool> {...}

do something like this:

public class DateSpan: ValueObject<Record<DateTime, DateTime, bool>> {...}

The ValueObject class would then expose the record to as a protected property and pass Equals, ToString... to the Record object. It would make the declarations a little bit more complicated, but your biggest drawback is not a problem anymore.

re: Creating an immutable value object in C# - Part V - Using a library

lucabol — Mon, 04 Feb 2008 20:07:41 GMT

I think I'm missing something. Aren't you still stealing the base class with the ValueObject class?

I.E. you cannot declare DateSpan to inherit from a MySpan class.

re: Creating an immutable value object in C# - Part V - Using a library

mg — Mon, 04 Feb 2008 22:25:00 GMT

Well, I was thinking about ValueObject more in terms of a type system base class, where you can put your additional behaviour and not spoil the Record class. You are right that still you cannot have a deeper hierarchy of types with this solution.

BTW: don't you think it would be nice to have a language support for immutable types? Something like:

public readonly class MyClass...

where all fields are readonly fields of readonly types?

re: Creating an immutable value object in C# - Part V - Using a library

lucabol — Mon, 04 Feb 2008 22:44:49 GMT

Yeah, you are right.

We talked about having first class readonly classes a bunch of times, but we never came up with a proposal we are happy with. We are still discussing the topic.

Code generation

Doekman — Wed, 06 Feb 2008 13:25:49 GMT

Isn't code generation a much better option at this time, while 1st class readonly classes aren't available?

re: Creating an immutable value object in C# - Part V - Using a library

lucabol — Wed, 06 Feb 2008 19:02:03 GMT

It is an option. I wouldn't say it is better. It has pros and cons (i.e. readibility, amount of code, mantainability).

As for me, I prefer library solutions to codegen whenever available (and roughly usable).

re: Creating an immutable value object in C# - Part V - Using a library

qq — Sat, 09 Feb 2008 00:53:24 GMT

I think you guys in immutable space have frankly lost it. It is not new, it is common principles that do not apply in all fields, and just because functional attempts are again popular you are hitting on attempting to solve a problem with a wrong tool: .net type system.

If you think magically you will somehow parallelise code and algorithms, you are in for a big 'immutable surprise'.

No, silver, bullet..

re: Creating an immutable value object in C# - Part V - Using a library

lucabol — Sat, 09 Feb 2008 01:32:41 GMT

All these posts say is: iff you need an immutable class, here are a bunch of options of how to do it in C#.

I don't think I'm claiming anything more than that. Am I?

A C# library to write functional code - Part II - Tuples

Luca Bolognese's WebLog — Wed, 09 Apr 2008 00:06:25 GMT

Previous posts: Part I - Background Tuples are a way for you not to name things. In Object Oriented languages