reflect these as top
types:
- RefObject and ValObject are (somewhat special) classes. We spell (at least
in the class file) “value class” as “class X extends ValObject”. We implicitly
rewrite reference classes at runtime that extend Object to extend RefObject
instead. This has obvious
e vague, but its
>> conceivable we may want methods on ValObject that are members of all values.
>>
>>
>> There’s been three ways proposed (so far) that we might reflect these as top
>> types:
>>
>> - RefObject and ValObject are (somewhat special)
Yes, that's a nice one.
On Apr 8, 2019, at 1:24 PM, Brian Goetz wrote:
>
> Sergey pointed out this additional benefit of RefObject: code that really
> doesn’t want to deal with values, or pay any of the taxes that arise from the
> fact that values are Object, such as acmp overhead.
During the last EG call, I suggested there are benefits to having both
RefObject and ValObject be classes rather than interfaces.
Old code should be able work with both values and references (that's the
promise of L-World after all!). New code should be able to opt into whether it
wan
the last EG call, I suggested there are benefits to having both
RefObject and ValObject be classes rather than interfaces.
Old code should be able work with both values and references (that's the
promise of L-World after all!). New code should be able to opt into whether it
wants to handl
g.On 4/12/2019 11:16 AM, Daniel Heidinga wrote:> During the last EG call, I suggested there are benefits to having both RefObject and ValObject be classes rather than interfaces.>> Old code should be able work with both values and references (that's the promise of L-World after all!). N
The gordian knot here is that whenever you see Object as part of a
*type* you'd like to interpret it as a top type (the root of the
hierarchy). OTOH, when you see Object as part of an *expression* you'd
like to interpret it as something else (e.g. RefObject). And there are
also things in betwee
But it seems like we have already ruled this out - since, if
typeof(new Object()) is 'RefObject', you don't want RefObject <: Object.
I think you misunderstood the "want" here (though it still may not be
possible.)
The desired model is:
- Object is the top type. Everything is an Object.
On 15/04/2019 13:06, Brian Goetz wrote:
But it seems like we have already ruled this out - since, if
typeof(new Object()) is 'RefObject', you don't want RefObject <: Object.
I think you misunderstood the "want" here (though it still may not be
possible.)
The desired model is:
- Object
- Mail original -
> De: "Maurizio Cimadamore"
> À: "Brian Goetz" , "valhalla-spec-experts"
>
> Envoyé: Lundi 15 Avril 2019 14:20:35
> Objet: Re: RefObject and ValObject
> On 15/04/2019 13:06, Brian Goetz wrote:
>>
>>
>
> But the other concerns remain, e.g. as to the fact that the boundary between
> reinterpreted types (Object as RefObject) and non-reinterpreted types (Object
> as top type) seems very fuzzy.
Right, which is why we’re still searching for an answer :)
We really, really want to be able to repr
Mu suggestion here is to leave subtyping on the side, at least for now
and use some other way to describe what's going on.
Let's model the value vs. reference constraint explicitly - e.g. with
'val' and 'ref' type kinds (and let's not open the can worm as to what
the syntax should be, whether
> Let's model the value vs. reference constraint explicitly - e.g. with 'val'
> and 'ref' type kinds (and let's not open the can worm as to what the syntax
> should be, whether it should be a type anno, etc.)
>
> So:
>
> val Object ---> accepts all values
> ref Object ---> accepts all reference
On 15/04/2019 15:38, Brian Goetz wrote:
Let's model the value vs. reference constraint explicitly - e.g. with
'val' and 'ref' type kinds (and let's not open the can worm as to
what the syntax should be, whether it should be a type anno, etc.)
So:
val Object ---> accepts all values
ref Obj
>
> Well, not quite. The choice is between treating 'new Object' specially or
> not. If it's not treated specially there is no new scary type. It's just
> that`new Object` might not have the properties one might hope for (but again,
> those same properties would be lost as soon as you touch the
> De: "Brian Goetz"
> À: "Maurizio Cimadamore"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 16:38:58
> Objet: Re: RefObject and ValObject
>> Let's model the value vs. reference constraint explicitly - e.g. with 'val&
>
> Your idea of treating Object as abstract is, I believe, a sound one (which
> doesn't need any extra rule) - but we might have to figure out some story for
> anonymous inner classes of the kind `new Object() { ... }`.
After thinking about it for all of five minutes, I think this may have bro
Please, no.
> On Apr 15, 2019, at 11:03 AM, Remi Forax wrote:
>
>
>
> De: "Brian Goetz"
> À: "Maurizio Cimadamore"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 16:38:58
> Objet: Re: RefObject and ValObject
> Let
emi Forax wrote:
*De: *"Brian Goetz"
*À: *"Maurizio Cimadamore"
*Cc: *"valhalla-spec-experts"
*Envoyé: *Lundi 15 Avril 2019 16:38:58
*Objet: *Re: RefObject and ValObject
Let's model the value vs. r
> For (2) the proposal I saw earlier said something like, we'd like for `new
> Object` to mean REFERENCE. I think that is a siren song, and this issue has
> been addressed by Brian's proposal to deal with `new Object` as a migration
> problem. Rather than suggesting to use some static factory in
> De: "Brian Goetz"
> À: "Maurizio Cimadamore"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 17:23:36
> Objet: Re: RefObject and ValObject
>> Your idea of treating Object as abstract is, I believe, a sound one (which
>> d
>
> It's not a minor change, and all code that uses a type parameter that have
> Object as bound will become ambiguous.
I don’t think so. You can’t say
new T()
when T is bounded at Object (or anything, for that matter.).
What ambiguity are you afraid of here?
Avoid the Bikeshed! Make sure that temporary or provisional
syntaxes look __Different from permanent ones.
On Apr 15, 2019, at 8:03 AM, Remi Forax wrote:
>
> val, ref and any only applies to Object.
>
> if you prefer in term of notation, let's rename ref Object to Object?, val
> Object to Obj
I think this hangs together very well.
For legacy bytecode (only), the JVM has to be willing to do
these one-time fudges:
- rewrite new java/lang/Object to new java/lang/RefObject
- rewrite invokespecial java/lang/Object.()V to
invokespecial java/lang/RefObject.()V
The verifier can observe th
On 4/15/19 11:23 AM, Brian Goetz wrote:
> Then we have:
>
> abstract class Object { }
> abstract class RefObject <: Object { }
> abstract class ValObject <: Object { }
>
I also think it is plausible. As one part of migration story, maybe the
public no-arg constructor could be explici
Maybe (Remi correct me if I'm wrong), the problem Remi was referring to
is that we also have existing generic declarations like Object> which, in the new world, will mean either VALUE or REFERENCE. I
think this is a consequence of the choice (1) I described in my email -
e.g. reinterpret Object
That’s right, as we think that will be the best default. Obviously in some
cases users will want to re-bound to .
(For existing code; this comes with compatibility concerns, which we can handle
in various ways. The standard trick to change a bound without changing erasure
is to bound at Objec
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "Maurizio Cimadamore" ,
> "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 20:00:52
> Objet: Re: RefObject and ValObject
>> It's not a minor change, and all code that uses a ty
gt; Cc: "Brian Goetz" , "valhalla-spec-experts"
>
> Envoyé: Lundi 15 Avril 2019 20:13:50
> Objet: Re: RefObject and ValObject
> Avoid the Bikeshed! Make sure that temporary or provisional
> syntaxes look __Different from permanent ones.
>
> On Apr 15,
>
> 1) any codes that has inference
>var list = List.of(new Foo(), new Bar());
> will be inferred as List instead of List, so calling a
> method that takes a List will not compile anymore.
Not to dismiss the “what about inference” issue, but any code that combines
`var` with `List,o
> De: "Maurizio Cimadamore"
> À: "Brian Goetz" , "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 22:23:25
> Objet: Re: RefObject and ValObject
> Maybe (Remi correct me if I'm wrong), the problem R
> yes !
> all generics will suddenly accept value types.
>
Yes, this is by design. If you can’t have an ArrayList of Point, that would be
terrible. Of course, until we have specialization (later in the story), these
will be erased, and restricted to the nullable projection.
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "Maurizio Cimadamore" ,
> "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 22:39:43
> Objet: Re: RefObject and ValObject
>> 1) any codes that has inference
>> var list = List
I think we should be ok inference-wise, except of course for edge cases
(like vars) which exposes the guts of the inference engine.
In normal cases like:
List list = List.of(new Foo(), new Bar())
the equality constraint on the LHS should force a solution which
overrides the new 'RefObject' bo
> De: "Maurizio Cimadamore"
> À: "Brian Goetz" , "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 22:53:49
> Objet: Re: RefObject and ValObject
> I think we should be ok inference-wise, except of course
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "Maurizio Cimadamore" ,
> "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 22:46:08
> Objet: Re: RefObject and ValObject
>> yes !
>> all generics will suddenly accept val
; ,
> "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 22:46:08
> Objet: Re: RefObject and ValObject
> yes !
> all generics will suddenly accept value types.
>
>
> Yes, this is by design. If you can’t have an ArrayList of Point, that would
> be terr
> V <: V? by value set inclusion; V? is the type obtained by adjoining `null`
> to the value set of V.
Looking for.a better name for this. :”Nullable value types” is a terrible
name, so I don’t want to say that. (Too confusing with null-default value
types.). They could properly be define a
The word "reference" is available and fits the bill.
"nullable reference type"
> On Apr 15, 2019, at 2:23 PM, Brian Goetz wrote:
>
>> V <: V? by value set inclusion; V? is the type obtained by adjoining `null`
>> to the value set of V.
>
> Looking for.a better name for this. :”Nullable valu
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 23:23:57
> Objet: Re: RefObject and ValObject
>> V <: V? by value set inclusion; V? is the type obtained by adjoining `null`
>> to
Most of what i wrote in the L10/L20 memo is accurate :)
> On Apr 15, 2019, at 5:32 PM, fo...@univ-mlv.fr wrote:
>
>
>
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "valhalla-spec-experts"
> Envoyé: Lundi 15 Avril 2019 23:23:57
>
On 15/04/2019 21:54, fo...@univ-mlv.fr wrote:
m(List list ) { ... }
...
m(List.of(new Foo(), new Bar()));
Slightly incorrect sir :-)
This is effectively equivalent to the example I wrote earlier
List list = List.of(...)
The expected type will force the equality constraint and will dri
quot;John Rose"
>> À: "Remi Forax" , "Maurizio Cimadamore"
>>
>> Cc: "Brian Goetz" , "valhalla-spec-experts"
>>
>> Envoyé: Lundi 15 Avril 2019 20:13:50
>> Objet: Re: RefObject and ValObject
>
>> Avoid the Bikeshed! Make sure that temporary or provisional
>> syntaxes look __Different from permanent ones.
>>
43 matches
Mail list logo