Thoughts on peeling and readability

[Vitaly Davidovich]

Awesome! Fully understand there are more fundamental/basic issues to sort
out, as you said, but wanted to see what you guys are thinking.

I have some internal cases where I could make use of this quite a bit;
certain types have characteristics that enable dense/creative ways of
storing them.

sent from my phone
On Dec 11, 2015 11:28 AM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> 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> 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
>>>
>>
>>
>