caution: bleeding-edge ahead!

[Palo Marton]

In some previous post in this thread there was a suggestion to use "class
aliasing" as a solution to manual specialization of a class. I don't agree
with that. But thinking of aliases, they might be useful for something else:

Quote from Brian's "State of specialization":

a successful conversion would be to end up with IntStream extends
Stream<int> and be able to jettison the large amount of hand-specialized
code that the streams library contains.


If this will be achieved (and that's a big IF), then may be it can be
pushed even further to:

IntStream.class == Stream<int>.class


On the surface it seems that all that is needed for this is to have some
ability to specify class names for some specializations, something like:
"class IntStream aliasof Stream<int>; (no class body here)". On the
JVM/bytecode level this will mean that specialized class should get
specified name instead of some unspecified JVM dependent name.

But this depends on that big IF and that is probably what the JVM guys are
working on at the moment.


On Tue, Jan 13, 2015 at 3:38 PM, Timo Kinnunen <timo.kinnunen at gmail.com>
wrote:

>
> I think it could be used to address that as well. You can’t add layers to
> an existing class without rewriting its source code, right? So under that
> allowance, you could rewrite java.util.List by splitting it into two, like
> this:
>
>
> public interface List<T> extends PackagePrivateBaseList<T> {
>
>
>   T remove(int index);
>
>   boolean remove(Object o);
>
>
> }
>
>
>
> Then provide another interface for value types:
>
>
>
>
> interface PackagePrivateAnyList<any T> __aliasOf List<any T> extends
> PackagePrivateBaseList<any T> {
>
>
>   T removeByIndex(int index);
>
>   boolean removeByValue(T o);
>
>
> }
>
>
>
> And finally provide implementations for references and values,
> respectively:
>
>
> public class ArrayList<T> implements List<T> { /* … */ }
>
>
> class PackagePrivateArrayAnyList<any T> __aliasOf ArrayList<any T>
> implements List<any T> { /* … */ }
>
>
>
>
> This is probably not binary-compatible as-is, but maybe that could be
> addressed as well.
>
>
>
>
> --
> Have a nice day,
> Timo.
>
> Sent from Windows Mail
>
>
>
>
>
> From: Maurizio Cimadamore
> Sent: ‎Tuesday‎, ‎January‎ ‎13‎, ‎2015 ‎13‎:‎07
> To: Ali Ebrahimi, Timo Kinnunen
> Cc: Brian Goetz, valhalla-dev at openjdk.java.net
>
>
>
>
> 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>
> 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
>
>
>
>
> --
>
>
>
>
> Best Regards,
>
> Ali Ebrahimi
>