caution: bleeding-edge ahead!

[Ali Ebrahimi]

I sorry to say that your proposal is heavily depend on code order and may
we get unexpected (or not easily understandable) result if code order
changed or if a new case inserted in between of existing cases.
What if we want different signatures for peeledMethod?

I'm thinking of maximum code reuse.

On Tue, Jan 13, 2015 at 12:54 PM, Palo Marton <palo.marton at gmail.com> wrote:

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


-- 

Best Regards,
Ali Ebrahimi