Thoughts on peeling and readability

[Brian Goetz]

Yes, there are thoughts and plans :)  But we're focusing first on the 
"how do I write a fully generic ArrayList" first, and then we'll turn to 
how this could be further hand-optimized for specific instantiations.

(It's worth noting, though, there are actually not that many concrete 
examples.  ArrayList<boolean> is an obvious one, as is HashMap<int,int> 
(the literature is full of optimized Map implementations for this 
case.)  And things like Optional<ref>, which can have a more compact 
representation than Optional<int>.  Beyond this, the "obvious" examples 
tail off pretty quickly.)

On 12/11/2015 10:56 AM, Vitaly Davidovich wrote:
>
> Brian,
>
> Like Paul, I also like the peeling/specialization approach.  I just 
> wanted to quickly ask if there's still a plan to allow specialization 
> of storage based on concrete type - think ArrayList<boolean> being a 
> bit vector internally, as an example.  Any current thoughts/plans?
>
> sent from my phone
>
> On Dec 11, 2015 8:57 AM, "Brian Goetz" <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     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
>
>