caution: bleeding-edge ahead!

[Ali Ebrahimi]

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>
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 <maurizio.cimadamore at oracle.com>
> *Sent:* ‎Tuesday‎, ‎January‎ ‎13‎, ‎2015 ‎1‎:‎21
> *To:* Ali Ebrahimi <ali.ebrahimi1781 at gmail.com>, Brian Goetz
> <brian.goetz at oracle.com>
> *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
>



-- 

Best Regards,
Ali Ebrahimi