"Model 2" prototype status

[Simon Ochsenreither]

>    > > This is especially confusing given that the duplicated fields would
>    > > only exist for value types, while reference types would share the same
>    > > member.
> >  >   
>  My initial objection was about the comment that .NET goofed up, which I
> disagree with; whether something different needs to be done for java to
> maintain backcompat is a different (and likely) story.
> 

But then I think the argument about tying the lifetime of these statics to the
class artifact backing it is moot, isn't it?

Plus, this would be yet-another thing which would work slightly different and
expose implementation details to the user.

>   
>    > > I've spent a lot of time in Scala working to remove things where people
>    > > said "oh, you just need to spend 5 minutes learning it, and then it
>    > > will be fine!".
> >    Duplicated statics is certainly not a 5 minute tax on every present or
> > future Java developer, it's probably a magnitude more.
> >  > 

>  Otherwise, it bugs me that there's some sentiment that java developers are
> somehow incapable of learning anything "advanced", however you define that
> (I've seen this type of view expressed many times on this list and elsewhere).
>  I've never seen/heard of anyone complaining about how CLR handles static
> fields on generic types.  There are far more involved concepts that a java
> developer needs to become familiar with.  If one wants to be beginner
> friendly, then provide good documentation, examples, community, etc around the
> language rather than somehow dumbing the language down.
> 

I'm not sure how you get that impression from my reply. What I'm arguing against
is the notion that the ease of implementation for the compiler/language/runtime
author is more important than the time of developers. I don't question that
people can sit down and learn things, but I question the need for them to do
that in every case if a better design could have prevented that.

If every implementer says "ironing out the odd corners and inconsistencies of my
language feature is too much work, let the user deal with it", then we will have
a language which takes a lot of unwarranted time to learn. It's a bit like
non-metric systems. Sure, it's possible to learn them, but it's 2015, and people
ought to have better things to do than deal with inches and foots.

Of course there are more involved concepts, and of course documentation,
examples, community can help, but not having to support people learning the
quirks – because there are no quirks – is a superior approach in my opinion.

>From my point of view the question is "do we want to waste developer's time by
unnecessarily complicating the mental model of classes and instances?".