Scala Heaven and Hell — Michael Slinn

Sure, no one is diminishing the importance of micro-optimizations in the grand scheme of things, but that doesn’t necessarily mean that the everyday (Scala) developer should be familiar with those. More importantly, they should not be misguided to use them for optimizations when such optimizations are not required, which is often their case.

Perhaps I was too subtle. Let me try again:

  1. I agree to a certain extent with the speaker in that there should be more transparency regarding Scala’s documentation in general – more examples, more measurements (depends on the feature).
  2. I am not questioning opaques’ transparency as they are still WIP.
  3. I am asking that at the end, when opaques are no longer WIP, there will be some form of measurements available for the sake of transparency.

I would obviously prefer multiple benchmarks of complex real-world scenarios, but given that this might be hard to come by, I would compromise for “simple” (easy to grasp) micro-benchmarks – like the ones you provided here – along with an explanation of the mechanism, and preferably at least one anecdotal real-world example of where this technique has been proven to be valuable via some benchmarking (otherwise how can you tell that the technique was valuable?) which are cumbersome / time consuming to replicate.

I don’t know exactly what you mean by “clunky”, but I personally prefer a wrapper case class to (the currently proposed) opaque types from any perspective other than performance. But this is obviously a matter of opinion.

If that motivation was the only motivation for the proposal, then I would’ve imagined a much simpler and more concise solution. I actually suggested such a solution in the contributors thread, but perhaps such a solution is not possible.

It seems to me that the proposal evolved to not only serve that motivation, but to provide a better performing implementation of value classes, which serve as better performing wrappers. There are many other reasons why one might choose to use wrappers; they are not used just for distinguishing instances of the same underlying type.

Why do you think that would be the case here more than elsewhere?

I don’t understand why “transparency” is the right word to use here. What are you trying to convey by using “transparency” instead of, say, “comprehensiveness” (obviously in a different but related sentence)?

I don’t understand why “transparency” is the right word here, either, as opposed to, say, “tutorial” (again, different sentence but with similar sentiment).

This is nice to aspire to, but I don’t understand why you think this needs so much attention. Or do you think everything should get this much attention, and you’re just using this as an example?

Inasmuch as the effort can be redirected at will, I’d much rather have a good deep explanation about how to use givens, how inline works, etc…

Which I would prefer depends on what I meant. If I have case class Meter(m: Double) {}, then a bunch of things are true about it, like that it’s a subclass of AnyRef, which I don’t intend to be true.

I agree that opaque types as newtypes could be better sugared in order to make them less awkward. But the current example has the virtue of simplicity: all that they do is control whether you can know what the underlying type is, and otherwise you just use standard language features.

Your suggestion doesn’t work because it assumes that all you want is for the new type to be propagated everywhere. But meters times meters are not meters, nor is Cents(i).leadingZeros a currency.

1 Like

Yes, I was using opaques as an example, not necessarily the case that needs the most attention. I completely agree with you that there are far more important features that demand better documentation.

Perhaps “transparency” is not the exact word to describe what the speaker is asking for, but I think you got the gist of what is desired – better documentation of purpose, rationale, theory, use cases, measurements, etc.

I believe I have an answer for that, but I think this belongs to another thread. Would you care to comment on the dedicated opaques thread? I’d love to continue discussing this – it’s interesting :slight_smile: