Feedback on LW1 EAR

[Uberto Barbini]

Thank you very much for your detailed reply

The current prototype focus on the VM side of the value types, not the
> language side (the Java side), we have voluntarily move all the syntax
> discussion into a latter phase because, it's hard to do both the VM and the
> Java side at the same time so the only answer i can provide is we don't
> know :)
>
> So the syntax for accessing to the opcodes default and withfield are
> placeholders.
>
> That's said having a similar way to describe the initialization of a value
> type compared to the initialization of a class is something which is
> appealing, it's aligned with our moto .
>
>
I understand that is too early to discuss the syntax, but I was curious.
Thanks for the explanation. :)



> >
> > 2) Currently == won't compile. It will work eventually? It would be nice
> to
> > be able to control a few of operator (== + - * / say)...
>
> Again, it's a surface syntax discussion, so i will wanser with another
> question, what about == if the right side is an Object and the left side is
> a value type (or vice versa).
>
> What we know is that acmp (the bytecode of == between object) returns
> false if one of the Object is a value type.
>

I see... I'll stay tuned for updates in this area.
What I can say is that for Value object would be very useful to have
support to define a few basic operators.



> > 5) I saw that I can override toString() and call super.toString() to have
> > the standard Object behavior. I wonder if there will be some kind of base
> > class for all ValueTypes or not.
>
> no base class, a value type is a subtype of Object the same way an
> interface is a subtype of an Object,
> i.e. the relation between a value type and Object is not an inheritance
> relationship but a subtyping relationship,
> so you can see a value as an Object
>   Object o = value;
> but you can not expect all the methods of java.lang.Object to be available
> on a value type.
>
> The only 3 methods from j.l.Object available are toString(), equals() and
> hashCode().
> Currently, the compiler (and the JDK) provides a default implementation
> for those methods and you can override them.
>
>
thanks for the explanation. I understand better now.


>
> not only, but i let you find the other issues by yourself :)
>
> You can disable the error about generics using javac
> -XDallowGenericsOverValues,
> obviously, it doesn't provide any support of reified generics, it just
> disable the error.
>

Thanks, it actually helps a lot for testing Value Types on existing
projects.


Uberto