There are more suggestions than people discussing, and so far no suggestion has found any substantial support. So, I have decided to go ahead with transparent. transparent actually fits quite well with how we use the term currently. For inline methods, transparent means that the result type of the method does not figure in the expanded term. Conversely, an opaque alias means that the defined type does show up as its own entity, it is not just expanded away. By that terminology, normal type aliases are also transparent. So, transparent means that a type is somehow invisible or immaterial. The new meaning of transparent is analogous: A transparent trait does not show up in lubs, and, since the idea is that transparent traits are only used as mixins but not as types of values, would therefore not show up in any inferred type.
So I think it fits quite well, and we donât need to invent a new modifier or annotation for it.
At some point the analogy breaks down. You can see transparent objects mostly because of the change of index of refraction. You canât see transparent index-matched plastic inside water.
What is transparent here is the type of the trait. You still have the trait, you can still see the type explicitly, but it gets overlooked during type inference (so the inferred type is wider than it would be, overlooking the transparent trait).
Wouldnât transparent indicate that thereâs some sort of a relationship between this feature and opaque types?
Edit:
What I mean is that opaque types and mixin traits are not opposites, and renaming âmixinâ to âtransparentâ will cause confusion. From Opaque data type in Wikipedia:
In computer science an opaque data type is a data type whose concrete data structure is not defined in an interface. This enforces information hiding, since its values can only be manipulated by calling subroutines that have access to the missing information. The concrete representation of the type is hidden from its users, and the visible implementation is incomplete. A data type whose representation is visible is called transparent.
I donât see how mixin traits fall under the definition of âtransparentâ in the context of opaque types.
Most of programmers probably know transparent from CSS colors and similar stuff. So the âlevel of transparencyâ can change though.
And because not all of us are english native speakers, letâs not take dictionaries and dig through it. Itâs good enough.
Iâm not a native speaker either, and the first place Iâll go to when I see a word Iâm not familiar with (say, opaque) would be a dictionary or encyclopedia.
I would then assume a clear relationship between opaque-transparent keywords/standard library terms, just as I would expect it from private-public, long-short, some-none, etc.
Iâm actually in favor of @impl/entation, as it denotes that said trait is not a âdescriptiveâ/âinterfaceâ trait, but is intended to be used for inheriting functionality, which would raise the question of whether this functionality should be inherited or composed (at least for those concerned with composition over inheritance).
âlubexcludeâ seems like a clear winner to me. Intermediate and advanced Scala programmers will understand the name and beginners will be encouraged to learn what LUB stands for, which is necessary to go beyond basic use of the language.
Where as I would find the meaning of âtransparentâ opaque.
Whereas I agree with some of the above comments saying transparent is confusing, will transparent traits really be used often enough for that to become a problem? Thereâs a handful of traits in the standard library, and perhaps a few in other libraries, but I doubt these will ever be a common thing.
I would suggest that one of the principles of naming should be that misleading names should be avoided. It is better to use a name that conveys no meaning rather than one that is misleading. With commonly used terms, a new term name can often be desirable. I would suggest for example that it would be a really good idea for us to make up a word for âtype classâ. Rarely used terms should be meaningful and can be made long if necessary.