quot;
>> À: "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.
>>
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
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
>
> 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`
>
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
> 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
st means “T”.).
No flavor of Point is a subtype of any flavor of RefObject; ValObject and
RefObject are disjoint.
> On Apr 15, 2019, at 5:10 PM, fo...@univ-mlv.fr wrote:
>
>
>
> De: "Brian Goetz"
> À: "Remi Forax"
> Cc: "Maurizio Cimadamore"
> 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
> 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
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'
> 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
> 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 Remi w
>
> 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
rian 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, 2019, at 8:0
> 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 type pa
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
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
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
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
> 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
> 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
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
>
> 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
> 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'
>>
>
> 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
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
> 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
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
> 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
- 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:
>>
>>
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
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
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!). New code should be able
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 handle only references or valu
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.
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)
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
37 matches
Mail list logo
