"Model 2" prototype status

[Vitaly Davidovich]

>
> 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 suspect there's miscommunication.  I'm not saying that .NET's model is
appropriate for java today, I was only addressing the comment that .NET
somehow messed up by replicating static fields across instantiations of
generic types.

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.


I agree in principle.  "Better design" is subjective and context dependent
though.  What is the better design you have in mind?

On Thu, Aug 6, 2015 at 2:30 PM, Simon Ochsenreither <simon at ochsenreither.de>
wrote:

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