caution: bleeding-edge ahead!

[Ali Ebrahimi]

What is behavior if (Y is val and X is ref) or (Y is val or X is ref)?
We can have nested cases?
cases can have break statements?
case blocks can occur on class level?
.....?

On Tue, Jan 13, 2015 at 11:46 AM, Palo Marton <palo.marton at gmail.com> wrote:

> 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
>>
>
>


-- 

Best Regards,
Ali Ebrahimi