Opaque Types in Book

[bblfish]

https://github.com/scala/docs.scala-lang/blob/main/_overviews/scala3-book/types-opaque-types.md

That page is very nicely written and helpful.
Reading it does make me wonder if one looses the efficiency gains if one combines a bit of the abstraction with the opaque types.

For example it seems like it could still make sense to have a trait Logarithm with a type Logarithm and then have a couple of specialisations: one for Double and one for BigInt perhaps, ...

We have a library like that in Banana-RDF that used Projection types (see description here) which are deprecated and so I it could be that we want a way to replace those with opaque types. Note that we did have a leakage problem in banana-rdf.

[julienrf]

Hi @bblfish!

I don’t think this issue tracker is the best place to discuss your problem. Maybe open a thread on users.scala-lang.org?

The difference between opaque types and abstract type members is that abstract type members can have several “concretizations” (whereas opaque types alias to one thing only). Abstract type members seem to be what you are looking for, from what I understand. You might be interested in reading/watching the following resources:

• Polymorphic Embedding of DSLs, an academic article that shows how to use this pattern in Scala
• Existential Types — Make OOP Great Again, a talk I gave about it at Scala Days
• Uniting Church and State, a talk Noel Welsh gave at Scala Days
• endpoints4s, a library that uses this pattern

I hope that helps!

I am closing this issue, I suggest you open a discussion thread on users.scala-lang.org instead if you want to continue.

[bblfish]

Hi @julienrf, I agree that the larger question may not fit the place of the discussion for the book. I just added that as context for your interest.

But the narrower question - re the Logarithm - does seem very relevant to the book.
There has to be a simple answer: either adding the bit of abstraction looses the efficiency gains of opaque types or not.

• If not, then it would be worth stating that there
• If it does loose efficiency, then it is also important to mention, as those types of things are very difficult to test.

Here is some code that compiles

trait Logarithm {
	type Log
}

object Logarithm extends Logarithm {
	opaque type Log = Double
}

object BILog extends Logarithm {
	opaque type Log = BigDecimal
}

[julienrf]

OK, thank you for clarifying. I think the documentation already answers your question. With abstract type members, there is no cost of “wrapper” (unlike the first solution shown in that page), but there can be a boxing cost (see https://github.com/scala/docs.scala-lang/blob/main/_overviews/scala3-book/types-opaque-types.md#boxing-overhead)

[bblfish]

ok, thanks for all the pointers. I'll be checking them out soon, as I have to get round to upgrading that library.

[SethTisue]

If you see an opportunity for improving the book text, a pull request would be welcome.

[bblfish]

I guess it would be helpful if you could be extra clear that the code above is problematic (ie. that opaque types don't give the desired benefits in inherited traits as shown. )

Because I have a feeling that I would not know how to test that myself.