|
Just reading up on the new C# record keyword and nondestructive mutation[^] and wondering:
When was a time you used this concept? Anyone? Anyone...? Bueller...? Bueller...?
Just curious.
|
|
|
|
|
If it ain't in C# 3, I ain't used it.
Added:
Back in 1996 (?) I developed a system (DEC C on OpenVMS) which ran 24x7 and controlled a manufacturing process.
It had a configuration file. I wrote a simple editor for the configuration file. After the editor read the configuration file, it held two copies: a clean one and one to modify.
When the user exited the editor it would compare the two copies. If there were changes it would save them and then signal the main process to re-read the configuration file.
If there no changes, it wouldn't save and it wouldn't signal the main process to re-read the configuration file.
(Bear in mind that OpenVMS has a versioning file system.)
modified 17-Aug-23 11:58am.
|
|
|
|
|
I think you are like 4 versions behind the 8 ball, here. I know you don't care, but just saying...
|
|
|
|
|
I'm with you, there's just to many moving parts. KISS
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
I tried two things from C# 6 a while back, but found neither compelling enough to use it regularly.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
If I understand this correctly, we use nondestructive mutation all the time in JavaScript patterns. The most common scenario is with state management. While it may seem optimal to diff and mutate a state object, it's actually much slower in practice to run logic to figure out what's what. So, in JS land, a lot of times we'll just mutate copies of an object. If we need to diff, we can, but for every update we don't need to. It's much, much quicker.
Oh, and if anyone wants to insult JS, you better be an expert in it first.
Jeremy Falcon
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Oh, I should say, if you don't care about the deltas in state (so you can walk backwards in time, etc.) then just mutating an object directly is the quickest. But, if you want a paper trail, so to speak, the non-destructive approach is great.
Jeremy Falcon
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
|
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 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
|
|
|
|
|
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 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.
|
|
|
|
|
|
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.
|
|
|
|
|
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[^]).
|
|
|
|
|
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! 
|
|
|
|