Nondestructive mutation: tell me about a time

raddevus

I agree. I'm actually reading through the book, C# 10 In A Nutshell - Albahari (O'Reilly pub)[^]. The book is 1058 pages long and I can't believe how many concepts are in C# now. It's amazing and crazy. And, of course, overwhelming.

Mike Hankey

The last I got was C# 6.0 in a nutshell and it was overwhelming.

I don't think before I open my mouth, I like to be as surprised a everyone else. PartsBin an Electronics Part Organizer - Release Version 1.1.0 JaxCoder.com Latest Article: Simon Says, A Child's Game

raddevus

The reason I find it interesting too, is because of a Sea-Change in the development world. Back in the day C# OOP meant building classes and eschewing Structs. Now that has switched up quite a bit -- because of challenges devs face when attempting to alter the state of an object and then wondering if anyone else had a reference to the object also. This has gone much further in the iOS app-building world where that they say that everything you create should be a struct (not a class) so that you know you are only altering your object's state. Here's the official apple docs mentioning that: Choosing Between Structures and Classes | Apple Developer Documentation[^] Note the first item is: Use structures by default. Very interesting how things have changed.

Marc Clifton

We have scenarios where a record associated with a particular entity needs to be copied to as a child of a different parent entity, and the record includes some info on the parent. We clone the record and update its parent info, but we preserve the original record because it's copied and the front-end still needs to show parent info of the original record. That said, this is usually all front-end stuff. But I can definitely imagine a use-case for this on the backend. After all, that's why we have functions for shallow and deep cloning. ;)

Latest Articles:
A Lightweight Thread Safe In-Memory Keyed Generic Cache Collection Service A Dynamic Where Implementation for Entity Framework

PIEBALDconsult

I tried two things from C# 6 a while back, but found neither compelling enough to use it regularly.

Mike Hankey

Yeah I'm more of a brute force programmer, I don't use a lot of fancy stuff. Guess a carry over from using C and C++ for many years.

I don't think before I open my mouth, I like to be as surprised a everyone else. PartsBin an Electronics Part Organizer - Release Version 1.1.0 JaxCoder.com Latest Article: Simon Says, A Child's Game

jschell

Marc Clifton wrote:

with a particular entity needs to be copied to as a child of a different parent entity

Yes that is the example I thought of. Like many new features I can only see the new feature being helpful in a limited number of cases. Where it might be nice is when the original class has many attributes and the set (unfortunately) continues to grow. Then the more manual updates become more of a problem. If only because on a standard screen actually remembering that way down below in the class there is one (or more) copy ctors. Forgetting those can become a problem.

raddevus

Great examples and the value of the record keyword is that you get a lot of pre-created functionality as follows (the first one being the big one): - It writes a protected copy constructor (and a hidden Clone method) to facilitate nondestructive mutation. - It overrides/overloads the equality-related functions to implement structural equality.

PIEBALDconsult

Yes indeed. You have to know what the feature is doing in the background and what the limitations are. One example (not a new one of course) is the foreach loop -- in many cases, using a for loop is a better choice (when possible). I use a foreach loop only when there is no other option. I avoid Linq because it frequently does things which I can do better. As to C# 6 in particular: String Interpolation just isn't anything I would ever use. Earlier this year I wrote some code which does something similar though, taking some cues from it. C# 3 added Object and Collection Initializers (which are good), then C# 6 added Dictionary Initializers, which are really not any better and have no benefit over them as far as I can tell. A lot of these features make it easier for an unskilled developer to get something working, but at the cost of performance or flexibility.

Jeremy Falcon

raddevus wrote:

Now that has switched up quite a bit -- because of challenges devs face when attempting to alter the state of an object and then wondering if anyone else had a reference to the object also.

That's exactly what we do in JavaScript land. Everything's a reference (for the most part) in JS though, but in a lower-level languages that are multithreaded especially... can totally see the use here.

raddevus wrote:

This has gone much further in the iOS app-building world where that they say that everything you create should be a struct (not a class) so that you know you are only altering your object's state

That's cool. And you can still acehieve some OOP-like concepts with them. In JavaScript it's called object composition, but it's a way to achieve inheritance with objects that aren't a class (a struct basically). So, if I'm understanding this correctly, then perhaps the same could be done in other languages while also being non-destructive.

raddevus wrote:

Very interesting how things have changed.

Yeah it's pretty cool. Functional concepts are awesome. I mean, even if you love OOP, it's cool just seeing some things done in a different way.

Jeremy Falcon

Mike Hankey

The more that goes on behind the scenes the more that ccan go wrong and the harder to debug.

I don't think before I open my mouth, I like to be as surprised a everyone else. PartsBin an Electronics Part Organizer - Release Version 1.1.0 JaxCoder.com Latest Article: Simon Says, A Child's Game

Graeme_Grant

I find them useful as DTOs or for simple POCOs. This should be of interest to you: What are record types in C# and how they ACTUALLY work - YouTube[^] (I've skipped past his usual course ad) or jump forward to What records are behind the scenes[^]

Graeme

"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee

Davyd McColl

often, because a lot of common bugs can be traced back to unexpected mutations so if you send me an object and I don't know where it comes from, and I need a modified version of that to do something else, I'll make a copy first - I might use `.DeepClone()` from [NuGet Gallery | PeanutButter.Utils 3.0.167](https://www.nuget.org/packages/PeanutButter.Utils) followed by some (again, from that lib) `.With(...)` statements, eg ``` var foo = yourObject.DeepClone() .With(o => o.Name = o.Name.ToUpper()); ```

------------------------------------------------ If you say that getting the money is the most important thing You will spend your life completely wasting your time You will be doing things you don't like doing In order to go on living That is, to go on doing things you don't like doing Which is stupid. - Alan Watts https://www.youtube.com/watch?v=-gXTZM\_uPMY

raddevus

Graeme_Grant wrote:

I find them useful as DTOs or for simple POCOs.

That makes a lot of sense to me. I will check out the video. Thanks

raddevus

That is a great example that I understand better now because I watched the video: Coding Shorts: For The Record - Why You Should Use (Records in C#) - YouTube[^] Shawn Wildemuth (who is a great trainer and has created some top videos on PluralSight)

Graeme_Grant

raddevus wrote:

I will check out the video. Thanks

Nick is very good. He deep dives and is very thorough.

Graeme

"I fear not the man who has practiced ten thousand kicks one time, but I fear the man that has practiced one kick ten thousand times!" - Bruce Lee

obermd

I use this all the time. The naming is a little odd, but the concept is very simple: Copy an object and then change just those fields and properties you need to change. Seriously, I'm not sure this is useful as syntactic sugar except in very limited cases.

jochance

It's excellent for data contracts in web services where the reception is generally out of the client's control and whatever comes in the response, that is the object, because that is what came and it should probably never be mutable. The bottom line is that record can help enforce SOLID adherence. Many POCOs in general should now probably be defined as records instead of class. They're great. The only drawback/beef I have with them is having to do hokey workarounds to use them while targetting .NET Standard (C# 9–Use Record types in .NET Standard 2.0[^]).

User 11907673

Have I (to your point) occassionally has a use for this?...Yes. Is this overkill?...Yes. This is what you get when you open source things and can't think of a compelling reason to say "no". That being said there ARE some useful things that have come from the open sourcing. BTW, Top Level command NOT being one of them! :-)

Andrei Bozantan

This feature is useful to avoid all kind of bugs related to the usage of mutable values with multiple ownership shared through references. Think about scenarios when a method 'foo' receives an object as an input parameter. The initial contract is that the object's fields are not changed inside 'foo' . In a big codebase there would be many places where 'foo' becomes used over time, with the semantics of not changing the fields of the input object. If at some point someone makes a change in 'foo' to mutate one of the fields, this could cause many non obvious problems. In practice, in complex codebases these problems might be difficult to detect in a code review. Immutable types and non destructive mutation provide a solution to better express this kind of semantic.

If you can't explain something to a six year old, you really don't understand it yourself. (Albert Einstein)