"Bleah, Layers are too complicated!"

[Remi Forax]

The layer concept is not too far from the C++ class specialization concept.
Clearly, it's better IMO than the selector (the where clause) from the 
previous draft
because you can express that a specialization use different fields/type 
of fields.

Now, I think 'specialization' is a better term and 'ref' is not needed 
because it's the dual of 'any',
and I think i prefer to repeat all type variables (and their constraints).

|interface Map<any K, any V> {
     V getOrDefault(K key, V defaultValue);

     specialization Map<any K, V> {
         V get(K key);

         default V getOrDefault(K key, V defaultValue) {
             return containsKey(key) ? get(key) : defaultValue;
         }
     }
}|

||

Specialization is nevertheless complex but I think the syntax above is 
more Java-ish.

cheers,
Rémi

On 12/21/2014 05:57 PM, Brian Goetz wrote:
> I can understand why everyone is inclined to jump all over layers as 
> being "too complicated"; we have our own concerns there too, which I 
> think we've been honest about.  But, you're all getting ahead of 
> yourselves; it feels like you're having a collective panic attack of 
> "OMG, they're going to kill Java with complexity, so I'd better freak 
> out."
>
> So everyone ... relax.
>
> Right now, we're still *figuring out the problems* (which includes 
> separating the real problems from the perceived ones).  The one thing 
> I know is that the final solution will almost certainly look very 
> different.  (Everyone says they want us to work more openly, rather 
> than emerging from our cave with the final answer -- but you have to 
> do your part by showing some awareness that what we're sharing is 
> work-in-progress.)
>
> We've only thought about these issues for maybe a thousand hours so 
> far; that's not enough to get a good answer to hard problems like 
> this.  So *of course* the solutions we've got so far are half-baked.  
> How could they be anything else?
>
> Until we fully understand the problems, we are going to focus on the 
> theoretical characteristics of the possible solution, how well it 
> solves the problem, and how the solutions fit in with how the language 
> actually works (i.e., the type system, overload selection, method 
> dispatch, etc).  The fact that it looms too large in the user model or 
> the syntax is weird or has a lot of surface for what feels like corner 
> cases can't be our top priority now; focusing on the surface aspects 
> distracts from figuring out whether we're even on the right track or not.
>
> Now, it's common that the solutions one ends up with after the first 
> or second or third round is still more complicated than you'd like, so 
> then begins the agonizing slow process of peeling back perceived 
> requirements in order to simplify how the solutions fit into the user 
> perception of the language.  It seems that people want to "help" by 
> jumping right to that end stage by saying "this problem isn't 
> important to solve".  But unexamined opinions of which problems can be 
> punted on is not really that helpful to us.
>
> The thoughts we're sharing are very much work in progress.  Please 
> engage accordingly; at this stage, constructive help looks like 
> generating better understanding of the problems.
>
>