This is a great example of one of the fundamental weaknesses of the OOP paradigm, and something that is bound to get exponentially worse as the domain logic gets larger and more complex. IMO, neither option really solves the problem in a satisfactory method -- admittedly, self-types are an elegant approach, albeit still just a Band-Aid to the larger problem.
I use this mechanism often to access a reference to an outer class when I'm creating inner classes, since in Scala you can't say 'MyOuterClass.this' like you can in Java.
great video but I am still a bit confused about the difference between self-types and inheritance. do you have any additional resources to research this subject? thanks!
F-bounded polymorphism is something else. It can be used in conjunction with self-types, but that's not the defining difference between self-types and inheritance.
What about an associated type? It seems to me that it achieves exactly the same as the self type, dunno why they needed to add yet another way to express the same.
@@rockthejvm I found that they are called "Abstract types" in Scala, and seems that this discussion has already been done in StackOverflow: stackoverflow.com/questions/1154571/scala-abstract-types-vs-generics
This is a great example of one of the fundamental weaknesses of the OOP paradigm, and something that is bound to get exponentially worse as the domain logic gets larger and more complex. IMO, neither option really solves the problem in a satisfactory method -- admittedly, self-types are an elegant approach, albeit still just a Band-Aid to the larger problem.
Keep videos coming, Daniel! That's gold!
Thanks! Share with whoever you think might find it useful!
Great video! One of the more concise and informative explanations of self types out there.
Glad you liked it!
Really well explained about self types and difference from inheritance using trait extensions
Very clearly explained. I learn new things every day. Thank you Daniel!
Daniel, you rock man! This explains things so clearly!
This is awesome!!.. I have been struggling to find out the meaning of this syntax in one of libraries..Blogs and article did't help.Thanks Daniel
Glad it was helpful!
Nice! But can you use this pattern (the Cake pattern?) to compose classes or is it for traits only?
Nice !! You should join Leo Benkel scala server. It is a place where they try to encourage budding scala devs
Amazing video, thx!
I use this mechanism often to access a reference to an outer class when I'm creating inner classes, since in Scala you can't say 'MyOuterClass.this' like you can in Java.
Yep!
Thank you again :) It's really helping me get better at writing code.
That's my goal!
great video but I am still a bit confused about the difference between self-types and inheritance. do you have any additional resources to research this subject? thanks!
How are you confused? Maybe I can help here.
13:11 people constantly ask me "WHAT THE F...undamental diffrence..."
It's clear thank you 🔥
That's my goal!
Great explanation! Thanks a lot!
Glad you liked it!
Couldn't you simply put a field of type Person into the Diet trait?
As always, there are multiple solutions to the same problem.
@@rockthejvm But what are the pros and cons of both?
Key difference is that self type can be generic, which is used in F-Bounded polymorphism.
F-bounded polymorphism is something else. It can be used in conjunction with self-types, but that's not the defining difference between self-types and inheritance.
What about an associated type? It seems to me that it achieves exactly the same as the self type, dunno why they needed to add yet another way to express the same.
What do you mean by associated type?
@@rockthejvm I found that they are called "Abstract types" in Scala, and seems that this discussion has already been done in StackOverflow: stackoverflow.com/questions/1154571/scala-abstract-types-vs-generics
@@moy2010 you mean abstract type members. These are different than self-types and they serve a different purpose.
Why not just add person to eat?
def eat(thing: Edible, person: Person): Boolean
This would be very similar to the extension option #1, because we bleed API dependencies from one type to the other.