Hi, thank you for making this video. I notice you mention several times that you lose the API of the underlying type, it is possible to define `opaque type Name
A more rudimentary thing you can do, if the underlying type is immutable (or you don't mind sharing mutable parts), is define e.g. `def asString(n: Name): String = n`. That way, if I'm outside the defining scope and I have an `n: Name` in hand, I can do `n.asString.length` or whatever other ways I want to interrogate the underlying string. If you make a `fromString` you can have fairly smooth two way traffic. Of course, if `opaque type A
@@JimBalter you are right, it defeats the purpose of encapsulation via opaque types. I checked if we could utilize the new export clauses within an extension block to selectively expose some methods, but it doesn't work unfortunately. In my opinion, we should have been able to say `export n.length` but compiler says def expected.
Nice and concise, thanks a lot :) I wish if you could add some concrete scenario where it would be better to opaque feature, just to notice the advantage of it over something else
Nice explanation! I like the fact that it's zero overhead. What do you mean by "it has its drawbacks, and notably the inability to use the API of the underlying type" -- isn't that the whole point? Or do you mean that there should be a more convenient shorthand for enabling a subset of the underlying type's API?
If you shadow a type and want to use some of its original API, you'd have to re-offer that API. This might be tedious, depending on what your use-case is.
Hey man, I love the explanations you are doing on Scala 3, but what would be a possible scenario in which an opaque type would be better than a value class wrapping a type? Value classes don't have overhead and additional data either and you can structure methods in them a little more clearly. You also have the option to hide the value's API or show it through `export` keywords.
at 7:50 you say "quote unquote static". why did you not say "quote static unquote"? how am i supposed to know how long the quote is? also it's "char" (tshar), not "car".
Opaque type is quite good to describe the protocol definitions which contains vast data format🥳
I love these videos soooo much... all rise for the almighty Daniel!
Hi, thank you for making this video. I notice you mention several times that you lose the API of the underlying type, it is possible to define `opaque type Name
Totally possible, never thought of that. Nice one!
You rarely want to inherit the entire API of the underlying type without restriction. That defeats the purpose of declaring the type opaque.
A more rudimentary thing you can do, if the underlying type is immutable (or you don't mind sharing mutable parts), is define e.g. `def asString(n: Name): String = n`. That way, if I'm outside the defining scope and I have an `n: Name` in hand, I can do `n.asString.length` or whatever other ways I want to interrogate the underlying string. If you make a `fromString` you can have fairly smooth two way traffic.
Of course, if `opaque type A
@@JimBalter you are right, it defeats the purpose of encapsulation via opaque types. I checked if we could utilize the new export clauses within an extension block to selectively expose some methods, but it doesn't work unfortunately. In my opinion, we should have been able to say `export n.length` but compiler says def expected.
This is cool.
In Scala 2 we extend Name to AnyVal so it gets some of the functionality on basic types and and we don't allocate the wrapper on heap.
The equivalent technique in Scala 2 is newtypes: github.com/estatico/scala-newtype
"I can't even spell my name..." lol fun times. I just watched the value types video released today. I am going to use these everywhere.
Glad these are useful!
Good explanation with examples. Thanks.
Glad it helped!
Nice and concise, thanks a lot :) I wish if you could add some concrete scenario where it would be better to opaque feature, just to notice the advantage of it over something else
Mostly the combination of API design + no-overhead benefits.
Nice explanation! I like the fact that it's zero overhead. What do you mean by "it has its drawbacks, and notably the inability to use the API of the underlying type" -- isn't that the whole point? Or do you mean that there should be a more convenient shorthand for enabling a subset of the underlying type's API?
If you shadow a type and want to use some of its original API, you'd have to re-offer that API. This might be tedious, depending on what your use-case is.
Hey man, I love the explanations you are doing on Scala 3, but what would be a possible scenario in which an opaque type would be better than a value class wrapping a type? Value classes don't have overhead and additional data either and you can structure methods in them a little more clearly. You also have the option to hide the value's API or show it through `export` keywords.
Nice suggestion - I'll document the difference in a future video/post.
at 7:50 you say "quote unquote static". why did you not say "quote static unquote"? how am i supposed to know how long the quote is?
also it's "char" (tshar), not "car".
😂
how is opaque type different from a private variable in java?
We're talking about defining types (not variables) - there's also the concept of a private field/method in Scala as well.
Understood. Thanks.
half transparency is 0x80, not 0x88.
😅 you get the idea
@@rockthejvm Sure, but I've found similar bugs that persisted for years in legacy code, always giving inferior results.