Thoughts on peeling and readability

[Maurizio Cimadamore]

Hi Paul,
thanks for the comments; we are aware that the syntax situation is a bit 
sad at the moment, and of course we wouldn't wish such a syntax to be 
forced on any user. But, in terms of expressiveness, we believe that the 
current prototype is powerful enough - i.e. it lets you do most of the 
things that are needed in order to workaround most of the problems we 
faced when trying to anyfy the collection library.

So, rest assured - the syntax tokens used currently are mere hooks for 
the compiler to get it to generate what we want. We are aware that the 
current approach is both too verbose and also very alien to the Java 
developer and we have already few promising alternatives which could 
retain same expressive power while being way more friendly to Java 
developers (unfortunately we cannot share much at this point in time).

Your idea of semi-subclasses is not that different from the concept of 
layering that was discussed few months ago in this list; while arguably 
cleaner, that too sparked some concerns about perceived complexity; it's 
definitively an option on the table, but we'd like something simpler.

Thanks
Maurizio

On 10/12/15 22:33, 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