Re: caution: bleeding-edge ahead!
Timo Kinnunen
timo.kinnunen at gmail.com
Tue Jan 13 14:38:53 UTC 2015
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
More information about the valhalla-dev
mailing list