Classes, specializations, and statics

[Simon Ochsenreither]

I'm very concerned about this proposal due to the mental overhead it incurs on
unsuspecting users.
 
While I agree that there are certain things which would be not
possible/inconvenient without this proposal, I think the disadvantages severely
out-weigh any benefits.
 
The way erasure was done allowed developers to write code without considering or
needing the know the inner workings of how generics where implemented, except
the occasional "why can't I have overloaded methods foo(List<Integer>) and
foo(List<String>)"?
Developers had instance-level members and class-level members.
 
This proposal forces every developer to open up the engine cover and understand
all the implications of introducing another level between instance-level members
and class-level members (and all the interactions with javac's ongoing erasure
of reference types, which means sometimes these specialization-level members
collapse into class-level members (reference types) and sometimes they don't
(value types)).
 
C# introduced something like this in C# 2 and I think from an ergonomic,
end-user perspective it has been a failure. Considering that Java needs to
support both "static" modes for all eternity, and unlike C#, Java still supports
accessing static members from instances, this will be a huge mess.
 
>From a Scala POV, I have no idea how this could be integrated properly, given
that the language has vastly simplified rules and a clear distinction where
members need to live. It would probably be one of those things which would end
up with no native support in the language, turning it from "new feature" into
"legacy stuff only supported for Java interop" right upon release.
 
Cheers,
 
Simon