you seem to have mixed things up: the Inner#Outer is called a type projection, the inner.Outer is a called a path dependent type, because it is prefixed by a object path. path dependent types are judged equal if their respective path prefixes can be resolved to the same stable object ref in the current scope
Also, note that type projections are being dropped from the language because they are unsound and in general it means that you could have just used a normal non-nested type. lptk.github.io/programming/2019/09/13/type-projection.html
Hm, thanks for the tip. The terminology seems a bit mixed in general, and that's how I made the most sense out of them. I'll read more on it and update the video as needed. I'm also aware that #T starting from an abstract path is not allowed anymore because it's not sound. I actually ran an exercise I used to show in Scala 2 with it, and it doesn't compile in Scala 3 anymore.
At 4:38 you can guard against these equalities on incompatible types by using the new Multiversal Equality feature. I like like your videos btw, got me inspired to do the puzzles from Advent of Code using Scala 3.
I try execute "println(innerA.getClass == innerB.getClass)" it return true. This make me confused. How it can be the same class but not the same type? detail is below: class Outer{class Inner} val outerA =new Outer; val innerA = new outerA.Inner; val outerB = new Outer; val innerB = new outerB.Inner; val inner:outerA.Inner = new outerB.Inner // as you said this wouldn't compile println(innerA.getClass == innerB.getClass) // but this line return true
Inner classes being different and outer classes being the same are two different problems. innerA.getClass = Class[Outer] innerB.getClass = Class[Outer] They're the same.
Nice. Now it's clear where this # in type lambda came from
you seem to have mixed things up: the Inner#Outer is called a type projection, the inner.Outer is a called a path dependent type, because it is prefixed by a object path. path dependent types are judged equal if their respective path prefixes can be resolved to the same stable object ref in the current scope
Also, note that type projections are being dropped from the language because they are unsound and in general it means that you could have just used a normal non-nested type. lptk.github.io/programming/2019/09/13/type-projection.html
Hm, thanks for the tip. The terminology seems a bit mixed in general, and that's how I made the most sense out of them. I'll read more on it and update the video as needed.
I'm also aware that #T starting from an abstract path is not allowed anymore because it's not sound. I actually ran an exercise I used to show in Scala 2 with it, and it doesn't compile in Scala 3 anymore.
github.com/lampepfl/dotty-feature-requests/issues/14
These are great videos. More Scala 3 please!
Incoming!
At 4:38 you can guard against these equalities on incompatible types by using the new Multiversal Equality feature. I like like your videos btw, got me inspired to do the puzzles from Advent of Code using Scala 3.
Yep, this is true - wanted to point out how the objects are different.
Really interesting. Thanks.
Glad you liked it!
Very clean explanation. Thank you.
Glad it helped!
I try execute "println(innerA.getClass == innerB.getClass)" it return true. This make me confused. How it can be the same class but not the same type?
detail is below:
class Outer{class Inner}
val outerA =new Outer;
val innerA = new outerA.Inner;
val outerB = new Outer;
val innerB = new outerB.Inner;
val inner:outerA.Inner = new outerB.Inner // as you said this wouldn't compile
println(innerA.getClass == innerB.getClass) // but this line return true
Inner classes being different and outer classes being the same are two different problems.
innerA.getClass = Class[Outer]
innerB.getClass = Class[Outer]
They're the same.