Improve opaque types

[dcsobral]

@gvolpe

But more importantly, there hasn’t been enough exploration on the design of a library like this. Haskell’s newtype isn’t a good match because Haskell doesn’t have inheritance, it doesn’t have to support the Java type hierarchy, and it isn’t object oriented.

Newtypes are not about inheritance

You completely misunderstood my point, which is that they are clearly defined in Haskell because it does not have to contend with a type system with inheritance and an object oriented design.

For example, if you “newtype” String, what is the type of its toString() method? Can you answer that without any reference to the type hierarchy?

You are basically saying it can be easily done without actually going to the trouble of explaining how it should be done. Give the exact rules and I’ll give examples that break them.

This is basically opaque types with extra steps, which should be better handled by the language itself. It doesn’t have anything to do with inheritance, or Java type hierarchy.

Why is it better handled by the language? It’s funny that you mention below that “the above response should also answer this question” but you actually didn’t answer anything. You say it is better handled by the language without any arguments to support it. I gave arguments to support the position that it is not handled better by the language.

simply inline/forwarding methods won’t work either for various reasons I remarked on before. Some existing methods would break the opacity and need to be excluded, some need modified type signatures, and some take primitive/string parameters that should not be changed to the opaque types, or have return values be likewise.

Exactly. This is why I believe this feature would be much better if implemented in the language itself.

You believe it needs to be implemented in the language itself because the classes from external libraries are full of special cases? That makes no sense whatsoever.