caution: bleeding-edge ahead!

[Palo Marton]

One possible abuse for all previously suggested syntaxes is that people may
tend to create completelly different set of methods for different layers.
And I think that IDE developers will hate us for that. (think of outline
view or refactorings for generics).

I would preferer to think of these as optional methods with syntax like
this:

class Test<any X, any Y> {
    optional void peeledMethod()
        case <val Y>: {
            //impl1
        }
        case <ref X>: {
            //impl2
        }
        default: {
           // imp3
        }
    }
}

It is switch-like syntax and behaviour. First case that matches will be
choosen as implementation and others ignored. If no case matches and there
is no default, then method is not supported in that specialization.

On Tue, Jan 13, 2015 at 7:46 AM, Timo Kinnunen <timo.kinnunen at gmail.com>
wrote:

> How about a new keyword “__aliasOf”, which would be used in a class
> declaration like this:
>
>
> public class IntArrayList __aliasOf ArrayList<int> implements List<int> {
>
> // int layer is implemented here
>
> }
>
>
>
>
> The effect of __aliasOf would be that user code could call
>
>
> new ArrayList<int>()
>
>
> but this would actually execute like a call to
>
>
> new IntArrayList()
>
>
> and user code would then be compiled against the methods and fields from
> IntArrayList.
>
>
>
> (And the name of the keyword is subject to change, of course.)
>
>
>
>
>
> --
> Have a nice day,
> Timo.
>
> Sent from Windows Mail
>
>
>
>
>
> From: Maurizio Cimadamore
> Sent: ‎Tuesday‎, ‎January‎ ‎13‎, ‎2015 ‎1‎:‎21
> To: Ali Ebrahimi, Brian Goetz
> Cc: valhalla-dev at openjdk.java.net
>
>
>
>
>
>
> On 12/01/15 23:32, Ali Ebrahimi wrote:
> > Why we can not adapt C++'s #if, #elif, #else, and #endif Directives
> > for java with java-like syntax. You can see that in hotspot code the
> > similar problems (OS depends-code) perfectly to be solved by Directives.
> >
> > So we can have support for multiple any type vars and nested layers,
> > and compiler can do flow analysis for nested layers (where clauses or
> > what ever you want).
> Hi Ali,
> I agree that, to some extent, the end goal of layers is to effectively
> enable some form of 'optional' membership/overriding which could also be
> thought of in terms of classic C++-style macros around method
> declarations/blocks etc. In fact, I think that, apart from partial
> abstractness, what's implemented right now is more or less functionally
> equivalent to layers (modulo bugs, of course). That said, I think we are
> in the search of something that would sit better with the Java
> programming model; granted, #ifdefs and friends will take you there, but
> I think it will also be overly powerful - and prone to be abused (and
> perhaps, as some of you have noted in this mailing list, layers has that
> problem); what if there was a nice little construct that, with minimal
> footprint could take you all the way there - meaning that you could
> retrofit the libraries you care about, w/o really adding a new powerful
> hammer to the language? I think that 'something' is the sort of magic we
> are after here.
>
> Maurizio
>