Thoughts on peeling and readability

[Brian Goetz]

First, remember that the current syntax is *deliberately* awful. The 
sole purpose of the current round is to determine if: there a model that 
(a) can handle the migration needs of the current libraries, (b) can be 
set firmly on a theoretical foundation, and (c) is not too foreign to 
the existing mindset of Java developers.

We've already gone through several rounds of refining the model and will 
go through several more.  Once we're satisfied with the above, then it 
becomes sensible to start to think about how the code looks!  The good 
news is that we might actually be getting there (unlike in the past few 
attempts.)

> Some of the Collection changes are incredibly big

They look that way now, but in the end, they won't be.  Most of the 
changes look "big" for purely accidental reasons.  About 75% of the 
lines of diff are because the compiler doesn't yet support inner 
classes, and so these have to be manually desugared, for example. And 
many of the implementations that are currently peeled as entire methods 
will instead be factored down into smaller peeled methods or into direct 
language support for type-dependent operation (e.g., null checks) so 
that no peeling is required.

So, don't freak out!


On 12/10/2015 5:33 PM, Paul Benedict wrote:
> I truly like the peeling concept. Kudos Brian, Maurizio, et al.
>
> My only difficulty is reading the source code that contains the peeling.
> When I read it, I become concerned that mixing value-based blocks and an
> object-based blocks diminishes comprehension. In a way, I feel transported
> into C with preprocessor directives. :-) I wish there was cleaner
> separation.
>
> Three points:
>
> 1) In particular, I find reading most harmed when __WhereRef or ___WhereVal
> is within a function. I don't like these blocks at all.
>
> 2) Declared at the method level, reading is easy -- because a method is
> complete and distinct. This may be, in fact, the happy medium and the most
> preferred way of coding it.
>
> 3) At the other extreme, have you explored allowing developers to write
> semi-subclasses? Sorry for the poor term, but I don't know what else to
> call it. Some of the Collection changes are incredibly big, and almost seem
> like half-and-half code. I am concerned that when the division becomes so
> enormous yet equal, maintainability will be difficult. Perhaps something
> like this can be explored:
>
> public abstract class AbstractCollection<any E> implements Collection<E> {
>    // shared
> }
>
> // in same compilation unit
> __WhereRef(E) AbstractCollection {
>      public String toString() { ... }
> }
>
> // in same compilation unit
> __WhereVal(E) AbstractCollection {
>      public String toString() { ... }
> }
>
> Cheers,
> Paul