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?
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.