alternatives or complements to layers

[Vitaly Davidovich]

I really hope we get proper generic constraints and not have to write
instanceof checks for such cases.  Also, I want it to be clear from looking
at the method definition that it really expects a SomeInterface type
internally and not just any plain T.  Think of declaring generic methods in
an interface that are constrained to be SomeInterface (or subtype) -- this
needs to be visible purely from interface, without looking at impl.

On Wed, Jan 7, 2015 at 11:36 AM, Peter Levart <peter.levart at gmail.com>
wrote:

> On 01/07/2015 04:39 PM, Maurizio Cimadamore wrote:
>
>>
>> On 07/01/15 15:37, Peter Levart wrote:
>>
>>> It was said that an option is for all value types (including primitives)
>>> to get 3 Object methods (hashCode, equals, toString). So at least println
>>> is doable.
>>>
>> Right - I was speaking more generally of all methods which are overloaded
>> on the parameter type with Object, int, long, ...
>>
>> Maurizio
>>
>
> Depends on how value types interact with interfaces. I think that the in
> following idiom, for example:
>
>
> interface SomeInterface {  method() { ...  } }
>
>
> <any T> void doSomething(T arg) {
>     if (arg instanceof SomeInterface) {
>         ((SomeInterface)arg).method(); ...
>     }
> }
>
>
> It would not be necessary to box the 'arg' (in specializations where T is
> value type) just to invoke an interface method on it. The expression "arg
> instanceof SomeInterface" could be evaluated at specialization time and
> replaced with either "true" or "false".
>
> The cast ((SomeInterface)arg) could be replaced during specialization with
> either "throw CCE" or no-op.
>
> So value types could expose common behaviour (like Formattable, etc...)
> even to "any T" methods without resorting to boxing (which specialization
> is trying to avoid).
>
>
>
> Peter
>
>