caution: bleeding-edge ahead!

[Palo Marton]

>
> What is behavior if (Y is val and X is ref)
>

In the above example it matches with first case <val Y>, so that block will
be used for implementation and others ignored (even if they match). Rule is
"First case that matches will be choosen as implementation and others
ignored.". They are taken in order as they are declared in the source code.

If there is a need to specialize on both X and Y, it can look like this:

case <val Y, ref X>:


> or (Y is val or X is ref)?
>

You will jave to write that as two case statements and repeat the same code
block in both of them (there is no fallthrough or break here). But do you
have any real life use case for something like that?

We can have nested cases?
>

No.

cases can have break statements?
>

No. What is between case statemant are just actual code blocks. Only one of
them will be choosen for each specialization.

case blocks can occur on class level?
>

This has to be decided, whether it should look like this:

optional void peeledMethod()
  case <...>: { ... }
  case <...>: { ... }
  case <...>: { ... }

Or this:

optional void peeledMethod() {
  case <...>: { ... }
  case <...>: { ... }
  case <...>: { ... }
}

Somebody who has experience with java source code parser should decide
which is better (I don't belong to that group).


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