Thoughts on peeling and readability

Vitaly Davidovich vitalyd at gmail.com
Fri Dec 11 15:56:32 UTC 2015


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


More information about the valhalla-dev mailing list