Using the variable instantiation to define if is primitive type (Bucket 3) or value type (Bucket 2)

[Mariell Hoversholm]

Hi Anderson,

I believe this could cause an issue for developers when it comes to reading
the
code: `new Point.ref(1, 1)` is clear in its intent that it wants to
instantiate
a _heap_ object as opposed to a 'primitive object'. It also makes it clear
that
they aren't necessarily the same type.

If Java were to 'flatten' (perhaps there is better terminology for this
case?)
the type into only `Point` (thereby allowing `new Point(1, 1)` to
instantiate
a new heap object), it could cause confusion. Furthermore, if we were to
require
a heap object (for nullability purposes?) in a method, this would be more
confusing:


    method(new Point(1, 1)); // Is this creating a `Point` or `Point.ref`?

    void method(@Nullable Point.ref point);


I am also somewhat unsure how the array behaviour would work in this case?
Arrays are themselves a 'new' type: beyond the primitives we have today
creating
e.g. `[I`, `[J`, etc., it would create either a `[QPrimitive;` (primitive
class)
or `[LPrimitive;` (heap class; `Point.ref[]`). Having the arrays 'hide' the
real
type with `new Point[10]` in fact being `new Point.ref[10]` while
`Point[10]` in
fact becomes `new Point[10]` is very confusing and may cause unwanted
problems.

The idea is interesting, I'm simply not sure from a consistency-to-the-user
standpoint: it would create differences I would not be welcoming of in a
language I use daily, nor do I believe others would either.

On Tue, 4 Jan 2022 at 13:33, Anderson Vasconcelos Pires <andvasp at gmail.com>
wrote:

> Hi guys,
>
> I am very excited about Valhalla and what it will do for Java. I was
> wondering if the language proposals could be simplified a little bit
> without affecting performance.
>
> Please let me (maybe the community) know if the proposal below could be
> applied or not.
>
> From the new proposal that separates the user type in 3 Buckets (1, 2, 3),
> I believe the Primitive.ref (Bucket 3) and value class (Bucket 2) are
> equivalent, right?
>
> If so, I was wondering if we could have just one class declaration and
> distinguish the variable from how it is created.
>
> The runtime variable would be a value object if we use the new keyword to
> instantiate the variable, if not would be primitive value. I think it makes
> a little bit of sense since the new is used to create an object today,
> right?
>
> See the example below:
>
> [primitive or value] class Point {
>     int x;
>     int y;
> }
>
> Point p1 = Point(1, 1); // primitive value   - p1 is value of Point. Could
> be defined at compile time as new Point() in the actual proposal;
> Point p2 = new Point(1, 1); // value object - p2 instance of Point.ref.
> Could be defined at compile time as new Point.ref();
>
> Assuming the Point.ref is a subtype of Point, I believe this could be
> possible, right? If necessary, the right type could be defined at compile
> time in some cases.
>
> I do not know if it would have extra cost. I hope not.
>
> private Point getPoint(boolean reference) {
>      if (reference)
>           return new Point(1, 1);
>       else
>           return Point(1, 1);
> }
>
> Point p1 = getPoint(true); // p1 runtime is a value object -> Point.ref
>
> The array would be like below.
>
> Point[] ps1 = Point[10];  // assert ps1[0].x == 0
> Point[] ps2 = new Point[10]; // assert ps2[0] == null
>
> In this way primitive variables could be null. I don't think this is a
> problem since the wrapper class looks like it will continue to be nullable.
> For another point of view, the builtin primitives cannot be null. An
> Advantage is that it would not be necessary to include T.ref at the return
> of Map.get.
>
> One doubt is about another [primitive or value] class that has [primitive
> or value] members like shown below.
>
> [primitive or value] class Rectangle {
>     Point low;
>     Point high;
> }
>
> Maybe it would be a problem because the object size could not be defined
> previously. But we may assume in this case the size of primitive value.
> This way, Rectangle would be flat.
>
> Thanks for your time and please let me know your thoughts about this
> proposal.
>
> Anderson.
>


-- 

*Mariell Hoversholm *(she/her)

Software Developer @ <https://aboutpaf.com>