caution: bleeding-edge ahead!

[Maurizio Cimadamore]

Timo, Ali,
type aliasing won't address all issues associated with layering - i.e. 
the fact that we'd like, for instance, to be able to say that a method 
remove(Object) only exists on reference-parameterized collections.

That said, something like type aliasing might be useful when doing 
wholesale specialization (i.e. custom specialized implementation for 
i.e. ArrayList<boolean>).

Maurizio

On 13/01/15 09:31, Ali Ebrahimi wrote:
> I don't see this how solves the problems layering tries to solve. Just 
> now we can alias IntStream as Stream<int> in User code maybe in import 
> statements.
>
> import j.u.IntStream as Stream<int>;
>
> Stream<int> intStream; // compiles as IntStream intStream;
>
>
> On Tue, Jan 13, 2015 at 10:16 AM, Timo Kinnunen 
> <timo.kinnunen at gmail.com <mailto: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 <mailto:maurizio.cimadamore at oracle.com>
>     *Sent:* ‎Tuesday‎, ‎January‎ ‎13‎, ‎2015 ‎1‎:‎21
>     *To:* Ali Ebrahimi <mailto:ali.ebrahimi1781 at gmail.com>, Brian
>     Goetz <mailto:brian.goetz at oracle.com>
>     *Cc:* valhalla-dev at openjdk.java.net
>     <mailto: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
>
>
>
>
> -- 
>
> Best Regards,
> Ali Ebrahimi