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

[Anderson Vasconcelos Pires]

Hi Mariell!

Thanks for your reply. Please check my answers in the email below.

The points that I would like to know if this proposal is possible to be
applied, if it has performance impact and another if people like it.

If it has performance impact, it is not a good idea and I think there is
but I have a hope.

My point to create this proposal is:

   - I prefer not to have .ref at language level.
   - I prefer not to have both value class and Primitive.ref, since they
   are equivalent.

In this proposal primitive can be null and I do not care but I care if it
has performance impact.

I understand that Primitive.ref is necessary for the JVM. Because of
development flexibility, maybe I will use more Primitive class than value
class and instantiate using .ref when I need nullability, atomicity even
though I don't like so much the .ref syntax;

But I see great progress in the Valhalla project and I am very excited and
anxious to be released. By the way I would like to congratulate the experts
for this excellent job!

On Wed, Jan 5, 2022 at 3:20 AM Mariell Hoversholm <
mariell.hoversholm at paf.com> wrote:

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

Yes. new Point.ref(1, 1) is more clear that is a reference 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:
>

In this proposal, primitive is nullable. Ok?
Point.ref is a sub type of Point. So creating new Point(1, 1) I am creating
Point.ref and using the Point interface that is the same. Like List list =
new ArrayList();


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

Is creating a Point.ref if you want Point you would use Point(1, 1) without
new.


>
>     void method(@Nullable Point.ref point);
>

Point.ref would not be possible to use. You have to use it like below.

    void method(Point 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>
>