valhalla-dev Digest, Vol 7, Issue 26

[Vitaly Davidovich]

So say I'm authoring a generic class and call System.out.println() - how do
I know which method is going to be called? Suppose println returned
different types depending on overload - what's my return value type? I
can't target type it because that implies I know what the generic type will
be and I don't,  I'm just shipping a generic library.

Now if System.out.println has a generic overload, I know where I'm calling
and what I'm getting back.  But there's no specialization here, this is
plain generic dispatch no different from today.

Sent from my phone
On Jan 7, 2015 6:21 PM, "Thomas W" <twhitmore.nz at gmail.com> wrote:

> Hi Peter, Vitaly,
>
> Thanks for your interesting ideas. Vitaly says:
>
> > Personally I'd handle primitives as if they were value types from day 1:
> > they get Object's hashCode, equals, and toString by allowing T.toString
> and
> > rewriting it to their corresponding XXX.toString.
>
> Sounds great, we need good basic integration of primitives & value types.
> Let's do it.
>
> Peter says:
>
> > While experimenting a bit with the current preliminary prototype, I found
> > myself on several occasions wanting to call a method from "normal" API.
> Say
> > System.out.println(x) with an x of type "any T". Usually a method that
> > already has various overloads or a method taking an Object. Javac
> refuses:
> >
> >      PrintStream.println(boolean)
> >      PrintStream.println(char)
> >      PrintStream.println(int)
> >      ..
> >      PrintStream.println(String)
> >      PrintStream.println(Object)
>
> This pattern is absolutely typical of existing "vari-typed" Java code &
> libraries. It's the only efficient way to receive an argument that may be
> of (logically) any type, and process that argument.
> I absolutely think this is something which we should target, and the
> specializer should be able to do.
>
> Essentially, this is our specialized code's interface to "the rest of the
> Java world". It really should be able to be efficient.
>
> Equals, hashCode and toString only take us so far..  there are a world of
> other interactions, which -- if designed for performance -- will be written
> in a similar manner to these.
>
>
> Regards,
> Thomas Whitmore
>