What should I do when I have to create immutable object but not all fields can be initialized due to data missing at the creation time?what is the best practice to complete created object with data?
It's probably depends when you are going to provide the rest values for an object. But here is a pattern that J. Skeet told: obj.Freeze(); //makes obj immutable
23:45 why are you asking ImmutableList who it is? You _say_ at 23:42 that they are _different instances_ . You check for that with ReferenceEquals. Object.ReferenceEquals(object, object) is for this purpose.
The usage of the service requires the additional knowledge of how to initialise it. If you hide access to the constructor and provide a factory to initialise the service, then you have one place that knows how to do it and hides the detail from consumers.
What I hear: > Mutability first, mutability opt-in. Unvoiced "im-" part makes it a challenge to follow the speaker, unless I already know what he trying to say.
public class Foo { public readonly int Lastname, Firstname; public Foo (string last, string first) { Lastname = last; Firstname = first; i do not understand why we should wait for c# version whatever or why we should use properties. Properties are syntactic sugar for methods. Nothing more, nothing less.
Lazy evaluation. You can have another part of the application add a filter to it and when you finally call in the data, you're only processing the data that is requested.
@@DryBones111 if it's not needed now, why is it declared now? What you say does sound reasonable at first, but I do not find them to be strong enough arguments. There are other constructs to do lazy eval.
@@GeorgeTsiros It's partly to do with keeping things open to extension and closed to modification. Your method can simply define the mapping (single responsibility) and return an IEnumerable (keeping in line with immutability). What happens to the enumerable from there doesn't matter but you know the mapping is done. LINQ is implemented using pure functions and will give you the immutability in a performant way. LINQ is also the most common API for these kinds of transformations on collections in C# code now. There's no good reason not to use something immutable, performant, and declarative for the majority of use cases.
@@geoffxander7970 Good, because being tolerant or inclusive about crap like this worse than supporting brexit. "Injected politics into the conversation" as if your entire life is not permeated by politics.
20:27 do i _need_ to explain what is wrong with this? 21:10 apparently i do! What the fuck is this? Repository.Init() should be *part of the constructor* because that is the sole purpose for _constructors with parameters_ to exist: Creating a _new_ object in a _well defined state_ . public Repo(Conf conf) {} That is what you want to achieve with the disaster at 21:10. You want to create a Repo with someConf. new Repo(someConf).
Won't matter much for many web backend-type uses. Sadly, I work in gamedev where every bit of performance genuinely counts and immutability often isn't an option.
Mutability is usually has much better performance , linq by it self is not that fast and efficient. But most of this is just nonsense, no reason to have to have everything imitable. That query could have been improved by not creating a new instance but returning the old one if there is no need to change. What ends up happening you copy paste a bunch of code because you need the "builder pattern".
@@FilipCordas The reason to go with immutability is to have a more stable and cleaner code (at a cost of performance ofc). But it could be useful when you don't need extreme performance and you have a large codebase. p.s. IMHO it's better to use functional language like F# for that matter thou (it has more performant immutability). (:
@@feafarot F# is not that good or readable, it has nice things but overall it ends as unreasonable mess with everything in line unable to figure out what is the beginning or end. And cleaner is a subjective term. immutability is not less performant when used correctly to avoid locks in parallel execution, but this sort of religious attitude is just silly, especially when used incorrectly like with the projection in the example it's going to end up bad just like any mutable code.
@@FilipCordas "it ends as unreasonable mess with everything in line" - Well that only means that code was written badly, spaghetti is never good. You can write F# code to be self-documented like in C#. "cleaner is a subjective term" - sure, from my experience, the more mutations in one place you have - harder to understand what's going on (imo). I agree that the example from the video with Select is weird (but honestly if there is like around 20 items to iterate over - that's nothing for most modern apps, in terms of performance).
This channel is a gold mine. Thanks to all participants that made this available to everyone for free!
I needed this talk 15 Years ago
I appreciate everyone's comments on this video - please let me know if you have any questions :) my twitter is twitter.com/schneidenbach
What level is this considered?
Be as blunt as you can.
For mutating immutable types, use the "With" function. That'll give you a new instance of that type with the changed properties. #languageext
If I had this guy as a teacher would have passed accreditation years back already
That's a really kind thing to say, thank you!
Maybe you shouldn't be trying to change the world, but creating a new version with the changes? ;)
What should I do when I have to create immutable object but not all fields can be initialized due to data missing at the creation time?what is the best practice to complete created object with data?
It's probably depends when you are going to provide the rest values for an object. But here is a pattern that J. Skeet told:
obj.Freeze(); //makes obj immutable
Try using a design pattern such as event-sourcing.
Make a new object when you have the missing values. If you have access to the "with" keyword its a lot easier
23:45 why are you asking ImmutableList who it is? You _say_ at 23:42 that they are _different instances_ . You check for that with ReferenceEquals. Object.ReferenceEquals(object, object) is for this purpose.
great talk. Factory of a Factory, to the Factory, Refactor the Factory, Factory lol.
25:41 What was wrong with public static Person PersonFrom(Employee e) => new Person(e.FirstName, e.LastName); ?!
I really don’t understand the benefit of a factory pattern over an init method in his example
The usage of the service requires the additional knowledge of how to initialise it. If you hide access to the constructor and provide a factory to initialise the service, then you have one place that knows how to do it and hides the detail from consumers.
What I hear:
> Mutability first, mutability opt-in.
Unvoiced "im-" part makes it a challenge to follow the speaker, unless I already know what he trying to say.
I kno...has been putting me off throughout the lecture :D
Ooh, that's good feedback! Thanks a lot!
public class Foo {
public readonly int Lastname, Firstname;
public Foo (string last, string first) {
Lastname = last;
Firstname = first;
i do not understand why we should wait for c# version whatever or why we should use properties. Properties are syntactic sugar for methods. Nothing more, nothing less.
don't ask me why i try to assign string values to int typed fields
18:47 why linq??? Array.ConvertAll not good enough? Why has linq become the go-to solution for everything these days?
Lazy evaluation. You can have another part of the application add a filter to it and when you finally call in the data, you're only processing the data that is requested.
@@DryBones111 if it's not needed now, why is it declared now? What you say does sound reasonable at first, but I do not find them to be strong enough arguments. There are other constructs to do lazy eval.
@@GeorgeTsiros It's partly to do with keeping things open to extension and closed to modification. Your method can simply define the mapping (single responsibility) and return an IEnumerable (keeping in line with immutability). What happens to the enumerable from there doesn't matter but you know the mapping is done. LINQ is implemented using pure functions and will give you the immutability in a performant way.
LINQ is also the most common API for these kinds of transformations on collections in C# code now. There's no good reason not to use something immutable, performant, and declarative for the majority of use cases.
@@DryBones111 that sounds more convincing
What if someone on your team supports Brexit?
The joke was neither tolerant nor inclusive and it needlessly injected politics into the conversation.
Those people are probably not open about it. And I don't blame them, the environment nowadays is very intolerant.
@@geoffxander7970 Good, because being tolerant or inclusive about crap like this worse than supporting brexit. "Injected politics into the conversation" as if your entire life is not permeated by politics.
20:27 do i _need_ to explain what is wrong with this?
21:10 apparently i do! What the fuck is this? Repository.Init() should be *part of the constructor* because that is the sole purpose for _constructors with parameters_ to exist: Creating a _new_ object in a _well defined state_ .
public Repo(Conf conf) {}
That is what you want to achieve with the disaster at 21:10. You want to create a Repo with someConf. new Repo(someConf).
Pro tip, avoid political "jokes" to avoid alienating half of your audience.
This. Not to mention that engineers are often among the most conservative professionals.
I.e. be professional.
The projection example has terrible performance
Won't matter much for many web backend-type uses. Sadly, I work in gamedev where every bit of performance genuinely counts and immutability often isn't an option.
Mutability is usually has much better performance , linq by it self is not that fast and efficient. But most of this is just nonsense, no reason to have to have everything imitable. That query could have been improved by not creating a new instance but returning the old one if there is no need to change. What ends up happening you copy paste a bunch of code because you need the "builder pattern".
@@FilipCordas The reason to go with immutability is to have a more stable and cleaner code (at a cost of performance ofc). But it could be useful when you don't need extreme performance and you have a large codebase.
p.s. IMHO it's better to use functional language like F# for that matter thou (it has more performant immutability). (:
@@feafarot F# is not that good or readable, it has nice things but overall it ends as unreasonable mess with everything in line unable to figure out what is the beginning or end. And cleaner is a subjective term. immutability is not less performant when used correctly to avoid locks in parallel execution, but this sort of religious attitude is just silly, especially when used incorrectly like with the projection in the example it's going to end up bad just like any mutable code.
@@FilipCordas "it ends as unreasonable mess with everything in line" - Well that only means that code was written badly, spaghetti is never good. You can write F# code to be self-documented like in C#. "cleaner is a subjective term" - sure, from my experience, the more mutations in one place you have - harder to understand what's going on (imo).
I agree that the example from the video with Select is weird (but honestly if there is like around 20 items to iterate over - that's nothing for most modern apps, in terms of performance).
Difficult speaker to follow with the constant mistakes and self-corrections. Perhaps practice your lecture more.