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
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
> Objet: Re: RefObject and ValObject
> V <: V? by value set inclusi
> 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
>> the value set of V.
> Looking for.a better name for this. :”N
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
> 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
In the document on “Towards a plan for L10 / L20” I tried to answer these, but
I got it slightly wrong. I said:
V <: V? <: ValObject <: Object
But really that should be
V <: V? <: ValObject? <: Object
V <: ValObject <: Object
V <: V? by value set inclusion; V? is the type obtained b
> 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 value types.
> Yes, this is by design. If you can’t have an ArrayList of Point
> 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 for edge cases (like
> vars) which exposes the guts of the inference
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: "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.of(new Foo(), new Bar());
>> will be inferred as List instead of List,
> 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: "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 was referring to is
> that
> we also have existing generic declaratio
>
> 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
It's not bikeshedding, hence the "if you prefer ...",
it's trying to explain that it's a typing issue and not a runtime class issue.
Rémi
- Mail original -
> De: "John Rose"
> À: "Remi Forax" , "Maurizio Cimadamore"
>
> Cc: "Brian Goetz" , "valhalla-spec-experts"
>
> Envoyé: Lundi 15
> 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 parameter that have
>> Object as bound will become ambiguous.
> I
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
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
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
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
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
>
> 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?
> 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
>> doesn't need any extra rule) - but we might have to figure ou
> 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
Again, I was not proposing we went down there (I like RefObject, ValObject).
But... using subclassing to have a semantics discussion has issues on
its own (e.g. should we use interfaces or classes), which I think are
distracting at this point.
Hence my use of an alternate notation in an attem
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's model the value vs. reference constraint explicitly - e.g. w
>
> 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
> 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'
>> and
>> 'ref' type kinds (and let's not open the can worm as
>
> 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
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
> 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
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 repr
- 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 it seems like we have already ruled this out - since, if
>>> t
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 Object.
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
36 matches
Mail list logo