This video contains wrong information: You should NOT use hash code in the equality operator. Two objects that are equal should have the same hash code, but two objects that are not equal can also share the same hash code. Mathematically, this is due to the pigeon hole principle. The Equatable package also does not use hash code in the equality function. Hash codes exist to speed up hash maps and other data structures. Finding an object in a map is much easier if you can boil it down to a simple integer value.
This is correct, overriding equality with hash code only can result in some very very serious bugs, especially data corruption. Please get this video reviewed by any SDE at Google and everyone will tell you the same thing, that this breaks the equality contract and is very bad. This video should be pulled for spouting this dangerous misinformation. Otherwise it would have been a great video.
@@fitness7065 Edited second part below: This is not overriding anything in the way equality works, it's just overriding the hash code for a Class that extends the Equatable package/class. So normal equality will be just fine and won't be broken. I previously stated that Dart uses the hashCode to compare equality of objects but that was incorrect. In the end, it natively uses the pointer address to compare two objects. Also, @Julien Scholz's edited statement that the Equatable package does not use the hashCode to do a equality check is correct. It does update the hashCode to be the same between two instances of the same class that have the same values however, so hash tables and the like would consider the object already existing if a second instance is added that has the same values. Finally, while it is possible that there would be collisions, doing a comparison with the hashCode as demonstrated in the video wouldn't be as catastrophic as is being suggested. The first check is that the two objects are of the same type. So for a collision to happen, you would have to have two objects of the same type that have values that then collide, which is a pretty unlikely situation in the real world.
@@Aragorn450 Hi Charlie, thanks for the reply! I'm referring to the override described at 3:37 in the video, and the explanation that begins a few seconds before that. That appears to be overriding the default equality and breaking the equality contract.
Hey all, thanks for the feedback! I didn't intend for that to be stopping point; merely a building block toward understanding what Equatable does and why you'd want to use it. I'll be more careful with phrasing around intermediate steps in the future.
@@laybunzz Thanks for all the great work, but substituting component wise comparison of fields in the equals operator with a single comparison of hash codes breaks the contract of the equals operator. Two objects that are equal must have the same hash code, but two objects which are not equal are allowed to have the same hash code, too.
@@gabrielterwesten3262 I don't think such substitution actually breaks the contract. Two equal objects (according to our new definition of equal) will always have the same hashcode. Non equal objects will never have the same hashcode, but that's not part of the contract. :) It can still be wrong though, since two objects that would not be equal by standard definition (comparing each field individually) might be accidentally detected as equal due to hash collisions.
@@dongdigital The contract of the equality operator and the hashCode getter as specified in the API docs are not really optional. Collections rely on the correct implementation of those contracts. The type of equality specified there cannot be implemented with hash codes because of the collisions.
What about deep nested Maps and Lists? Would equatable understand 2 deep nested maps are same? Does it do some recursion under the hood in order to override its hashmap?
Yes it does, with the help of the collections package, it checks if the properties in the props is a map, iterable or list and compares it with DeepCollectionEquality
Future is used because it provides a Boolean value in the future. Suppose you've to get data from some task but that task will take a few seconds or minutes to complete but it may block the main thread if we will wait for it. So to make the task asynchronous, we use await keyword and that's where Future value comes in. The task will complete asynchronously and then you'll get the value. You can further change the state of the widget to make changes in the screen using that awaited value. Hope this helps. :-)
@@prankcial4187 Bro thanks for replying, but my question is, when you get the asynchronous bool result it can't be used anywhere. The major use case of bool variable is to check whether the condition is true or false. Suppose I have written a function to check whether the device is connected to the internet or not, and it will ping to my server, and on successful connection it will return Future (true) on any socket exception (false). But the real problem is, you can't use the Future anywhere, neither in if else statement, nor you can assign it to other local bool variables. If you try to do so, the error will be: 'Future ' is not a subtype of type bool The internet checking example I mentioned was not a big issue, you can anyhow solve that by assigning the value to a global bool variable. But in some scenarios it will become really difficult to overcome this issue
This is so cool. But another issue u run into is if you want your class to extend another class. In Dart, a class can't extend more than one classes so it's impossible to extend Equattable and another class. A solution for this (if u use VSCode) is to install the Dart class generator extension. This would generate the equality code for u
@Yayo Arellano @sahil kumar oh cool. It's been long I used the package. I didn't know about that. But I think i'll stick to the vs code extension. Rather than importing another dependency, It's easier and better in my opinion to use the extension to generate the code for me. "cmd + ." is all I need.
You may use it in your unit tests. For example, if you wanna test if two instances of an object are equivalent, you can use the expect function of package test. It will use the equal operator, and by overriding the equal operator, we can verify if they are the "same" or not.
To be clear, it's not exactly overriding the operator, it's just overriding how Flutter gets the value of the specific class you've defined that has that override enabled. For instance, doing something like this wouldn't allow you to make 3 == 4 return true. But you COULD make A(1) == A(2) return true with this...
I love the Decoding Flutter series! 💜 On unrelated question though: What tool do you use to create these cute text animations? I mean the ones you use to show the code block changes in these videos.
Thanks, I see the link between const constructor in Flutter and that Flutter doesn't rebuild those const widget: the default equality must be used. Though would it be possible to override equality for a subclass of widget to avoid rebuild even with non const constructor?
Can someone comment down some good recourses ( including book , courses etc )to learn dart and flutter and how to develop a great app overall i have no prior experience in app development. i know about little bit about c and c++
Getting started is tricky sometimes, we do offer many resources to help you get started however! Check out our Begin learning Flutter series right here on UA-cam: goo.gle/3CL1VlD If you prefer written guides, we also have a Get started guide on our resource site: goo.gle/3SRCSDe We can't wait to see what you create 🙌 🌠
We're glad you found Craig's tutorial helpful, Alexandru! To help you on your Flutter journey, feel free to check out more Decoding Flutter episodes → goo.gle/DecodingFlutter Happy Fluttering 😁
We couldn't agree more, Pedro! We have even more resources for our Flutter community. Try your hand at one of our amazing codelabs, and the best part? You can follow along at your own pace 🙌: goo.gle/flutter-codelabs
@@dancovich First thing: There is only the == operator left for equality, so how do you differentiate equality and identity like Java does with equals() and ==? Second thing: To make equality manageable they offer a library and you have to extend Equatable - this really is so '90s.
@@marcom. Dart has the `identical` function, part of the SDK, which will always compare references. Dart approach is that == will aways run whatever routine is writen for the operator and "identical" will always compare references. The reason == compares references by default is because the Object class uses "identical" in its == operator, so every class inherits this behavior by default. So, both Java and Dart have two ways of comparing, one is overridable and one is not. Only difference is that in Dart what is overridable is the behavior of the operator while Java what is overridable is the method. This isn't more or less confusing, it's just a different approach for the same issue that these languages don't have any operator for saying you're copying the value of an object to another and not just copying the reference.
@@marcom. I understand your point, but you don't need to use equatable if you don't want to. I personally used it in the past, but nowadays, I prefer using a VS Code extension called Dart Data Class Generator to override the == operator and hashCode. I want my entities to be apart of any external dependencies, even if its a great package like equatable or dartz, for example. Dart is not a mess like other languages. Dart gives you the basics of a programming language, and by doing so, it can be really predictable and safe to use.
For example, Dart don't have interfaces. Instead, you should use abstract classes. Dart don't support method overloading, which is SUPER common in Java, but instead, you should use factories to "overload" constructors and create another function to "overload" a method. In my humble opinion, this is much better. Methods and constructors have meaningful names, and this is great in terms of readability.
🤯🤯🤯🤯 Determine objects equality by comparing hash only, without considering hash collision. And the equatable library mentioned actually does not determine object equality by comparing hash code as explained in the video, instead it does compare each value of fields. I’m not being picky, but as a in-depth educational video, I would say this is an unforgivable error! And this kind of mistake should not be hard to be caught by doing a simple peer review.
This video contains wrong information: You should NOT use hash code in the equality operator. Two objects that are equal should have the same hash code, but two objects that are not equal can also share the same hash code. Mathematically, this is due to the pigeon hole principle. The Equatable package also does not use hash code in the equality function.
Hash codes exist to speed up hash maps and other data structures. Finding an object in a map is much easier if you can boil it down to a simple integer value.
This is correct, overriding equality with hash code only can result in some very very serious bugs, especially data corruption. Please get this video reviewed by any SDE at Google and everyone will tell you the same thing, that this breaks the equality contract and is very bad. This video should be pulled for spouting this dangerous misinformation. Otherwise it would have been a great video.
@@fitness7065 Edited second part below:
This is not overriding anything in the way equality works, it's just overriding the hash code for a Class that extends the Equatable package/class. So normal equality will be just fine and won't be broken.
I previously stated that Dart uses the hashCode to compare equality of objects but that was incorrect. In the end, it natively uses the pointer address to compare two objects. Also, @Julien Scholz's edited statement that the Equatable package does not use the hashCode to do a equality check is correct. It does update the hashCode to be the same between two instances of the same class that have the same values however, so hash tables and the like would consider the object already existing if a second instance is added that has the same values.
Finally, while it is possible that there would be collisions, doing a comparison with the hashCode as demonstrated in the video wouldn't be as catastrophic as is being suggested. The first check is that the two objects are of the same type. So for a collision to happen, you would have to have two objects of the same type that have values that then collide, which is a pretty unlikely situation in the real world.
@@Aragorn450 Hi Charlie, thanks for the reply! I'm referring to the override described at 3:37 in the video, and the explanation that begins a few seconds before that. That appears to be overriding the default equality and breaking the equality contract.
Hey all, thanks for the feedback! I didn't intend for that to be stopping point; merely a building block toward understanding what Equatable does and why you'd want to use it. I'll be more careful with phrasing around intermediate steps in the future.
Equatable is a must use package for all flutter projects, it saves lot of time ❤️
Very clean explanation by Flutter Team. I love it. Thank you.
We always love hearing feedback from viewers like you! Glad to hear you enjoyed it. Thanks for the love 🙌
What about hash collisions? If 2 objects have same hash code doesn't mean that they are the same
Yes, hash collisions should always mean that two objects are "the same". The idea here is that you get to define what "the same" means!
@@laybunzz Thanks for all the great work, but substituting component wise comparison of fields in the equals operator with a single comparison of hash codes breaks the contract of the equals operator. Two objects that are equal must have the same hash code, but two objects which are not equal are allowed to have the same hash code, too.
@@gabrielterwesten3262 I don't think such substitution actually breaks the contract. Two equal objects (according to our new definition of equal) will always have the same hashcode. Non equal objects will never have the same hashcode, but that's not part of the contract. :)
It can still be wrong though, since two objects that would not be equal by standard definition (comparing each field individually) might be accidentally detected as equal due to hash collisions.
@@dongdigital The contract of the equality operator and the hashCode getter as specified in the API docs are not really optional. Collections rely on the correct implementation of those contracts. The type of equality specified there cannot be implemented with hash codes because of the collisions.
Thanks Craig and the Flutter team.
What about deep nested Maps and Lists? Would equatable understand 2 deep nested maps are same? Does it do some recursion under the hood in order to override its hashmap?
Yes it does, with the help of the collections package, it checks if the properties in the props is a map, iterable or list and compares it with DeepCollectionEquality
thank you very much
i have one important question
how did you animate the code like this :)
is there a specific method or tool to do that?
No answer 😭
@@abdullahaqrabawy6897 you could use microsoft powerpoint or other presentation software that support fade in
@@abdullahaqrabawy6897 We use After Effects!
I love the Flutter T-shirt
Also please decode bool vs Future, and what is the use use of Future when it can't be used to check condition
Future is used because it provides a Boolean value in the future. Suppose you've to get data from some task but that task will take a few seconds or minutes to complete but it may block the main thread if we will wait for it. So to make the task asynchronous, we use await keyword and that's where Future value comes in.
The task will complete asynchronously and then you'll get the value. You can further change the state of the widget to make changes in the screen using that awaited value.
Hope this helps. :-)
@@prankcial4187 Bro thanks for replying, but my question is, when you get the asynchronous bool result it can't be used anywhere.
The major use case of bool variable is to check whether the condition is true or false.
Suppose I have written a function to check whether the device is connected to the internet or not, and it will ping to my server, and on successful connection it will return Future (true) on any socket exception (false).
But the real problem is, you can't use the Future anywhere, neither in if else statement, nor you can assign it to other local bool variables.
If you try to do so, the error will be:
'Future ' is not a subtype of type bool
The internet checking example I mentioned was not a big issue, you can anyhow solve that by assigning the value to a global bool variable. But in some scenarios it will become really difficult to overcome this issue
This is so cool. But another issue u run into is if you want your class to extend another class. In Dart, a class can't extend more than one classes so it's impossible to extend Equattable and another class.
A solution for this (if u use VSCode) is to install the Dart class generator extension. This would generate the equality code for u
You have equatable mixin for that case.
Use equatable mixin. Avoid writing boilerplate code
@Yayo Arellano @sahil kumar oh cool. It's been long I used the package. I didn't know about that. But I think i'll stick to the vs code extension. Rather than importing another dependency, It's easier and better in my opinion to use the extension to generate the code for me. "cmd + ." is all I need.
Not sure I'm gonna use it, but it's amazing to know we can override an operator 😂
When using flutter_bloc it's a must have. It ensure that your state is well emitted and not removed because object seem the same.
You may use it in your unit tests. For example, if you wanna test if two instances of an object are equivalent, you can use the expect function of package test. It will use the equal operator, and by overriding the equal operator, we can verify if they are the "same" or not.
To be clear, it's not exactly overriding the operator, it's just overriding how Flutter gets the value of the specific class you've defined that has that override enabled. For instance, doing something like this wouldn't allow you to make 3 == 4 return true. But you COULD make A(1) == A(2) return true with this...
Thanks a lot for all the tips! I can't help falling in love with Flutter.
So what alternative do u use? Or you haven’t had an encounter with equalities?
Thanks Flutter team!
equatable is nice package, though it'd be great if there's data class on dart
I love the Decoding Flutter series! 💜
On unrelated question though: What tool do you use to create these cute text animations? I mean the ones you use to show the code block changes in these videos.
Thanks so much! As for the animations, we have a really talented team that uses After Effects to bring these videos to life :)
Thanks, I see the link between const constructor in Flutter and that Flutter doesn't rebuild those const widget: the default equality must be used.
Though would it be possible to override equality for a subclass of widget to avoid rebuild even with non const constructor?
Well it's really not, basically you should mostly compare the properties inside your logic rather then the class itself
What if i don't have final members in a class and i want to modify the objects' properties, what should i do?
very clean explanation.....
can you show me how to use regex to validate email and password in dart?
thank you
You just blew my mind! Cheers 🥂
Excellent explanation.💯
❄️ Freezed package handles everything under the hood
really really cool explanation !! keep it up.
Can someone comment down some good recourses ( including book , courses etc )to learn dart and flutter and how to develop a great app overall
i have no prior experience in app development.
i know about little bit about c and c++
Getting started is tricky sometimes, we do offer many resources to help you get started however!
Check out our Begin learning Flutter series right here on UA-cam: goo.gle/3CL1VlD
If you prefer written guides, we also have a Get started guide on our resource site: goo.gle/3SRCSDe
We can't wait to see what you create 🙌 🌠
@@flutterdev Thanks so much for this 🤗
I still prefer using "Command + n" -> "generate ==() and hashCode", it's way faster
Great vid!
We're glad you found Craig's tutorial helpful, Alexandru! To help you on your Flutter journey, feel free to check out more Decoding Flutter episodes → goo.gle/DecodingFlutter
Happy Fluttering 😁
@@flutterdev I will thx!
why to check if other is of type A just modify your == operator with covariant
Very useful. Thanks!
You've made a great point, Rudolf 🎯 Let us know how you'll be using this feature for your project or app!
Great one, ty
4:01 this is still bad: you have to repeat the field names inside the variable "props'".
Need something cleaner.
Sorry for being blunt. I like dart, and i hope you can improve this feature in the future
Thank u 😊
Perú: Algun ejemplo de como leer codigo de barras mediante PDA o Terminal Android Sunmi L2
AWESOME!
We couldn't agree more, Pedro! We have even more resources for our Flutter community. Try your hand at one of our amazing codelabs, and the best part? You can follow along at your own pace 🙌: goo.gle/flutter-codelabs
For once, the software is actually really useful
Freeeeeeeeeezed
Still topping😁
Great
It's odd to see that the newer language Dart even is a greater mess than Java when it comes to such basic concepts.
Why? Seems like many other languages, objects have their references compared unless you override the equality operator. What is a mess in this?
@@dancovich First thing: There is only the == operator left for equality, so how do you differentiate equality and identity like Java does with equals() and ==?
Second thing: To make equality manageable they offer a library and you have to extend Equatable - this really is so '90s.
@@marcom. Dart has the `identical` function, part of the SDK, which will always compare references. Dart approach is that == will aways run whatever routine is writen for the operator and "identical" will always compare references. The reason == compares references by default is because the Object class uses "identical" in its == operator, so every class inherits this behavior by default.
So, both Java and Dart have two ways of comparing, one is overridable and one is not. Only difference is that in Dart what is overridable is the behavior of the operator while Java what is overridable is the method. This isn't more or less confusing, it's just a different approach for the same issue that these languages don't have any operator for saying you're copying the value of an object to another and not just copying the reference.
@@marcom. I understand your point, but you don't need to use equatable if you don't want to. I personally used it in the past, but nowadays, I prefer using a VS Code extension called Dart Data Class Generator to override the == operator and hashCode. I want my entities to be apart of any external dependencies, even if its a great package like equatable or dartz, for example. Dart is not a mess like other languages. Dart gives you the basics of a programming language, and by doing so, it can be really predictable and safe to use.
For example, Dart don't have interfaces. Instead, you should use abstract classes. Dart don't support method overloading, which is SUPER common in Java, but instead, you should use factories to "overload" constructors and create another function to "overload" a method. In my humble opinion, this is much better. Methods and constructors have meaningful names, and this is great in terms of readability.
Just like JS Brother
Seriously??? Usin comparing hash codes while equals??? What’s about collisions?
After 3 years using Flutter I just realised the logo is a F.
omg...
Isn't this a poor language design? If a library can generate that for you, compiler should also be able to do it?
🤯🤯🤯🤯
Determine objects equality by comparing hash only, without considering hash collision.
And the equatable library mentioned actually does not determine object equality by comparing hash code as explained in the video, instead it does compare each value of fields.
I’m not being picky, but as a in-depth educational video, I would say this is an unforgivable error!
And this kind of mistake should not be hard to be caught by doing a simple peer review.
good thing freezed exist!
:)
Thanks for freezed package 🫡
You're truly welcome, Rohith. We're loving this cool package as well 🧊