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

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

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?

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

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

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

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