more
and ruled them out before sending. I like them "syntactically", supporting
the notion that an object's identity iis like an attribute, but to expose
that identity as a type of its own will not make sense.
Thanks for responding.
> --Dan
>
> >
> > Thoughts?
>
tity(o2) // this too
* System.identityEquals(o1, o2)
* o1 === o2
Thoughts?
On Tue, Apr 26, 2022 at 3:09 PM Kevin Bourrillion wrote:
> Above, when I said the proposed `==` behavior is "not a behavior that
> anyone ever *actually wants* -- unless they just happen to have no fields
> of re
ger.
Thoughts?
On Thu, May 12, 2022 at 3:14 PM Kevin Bourrillion wrote:
> I don't see the conflict. I'm saying, yeah, there *will* be exclamation
> fatigue until a feature comes along eventually to relieve it. (In the worst
> case, that's `public null-marked class...`; in the b
fault, but Kevin was, so I'll leave it to
> him to reconcile "ref-default is the right default" with "but,
> exclamation fatigue.")
>
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
and B3!, and we don't know how to find one for B2!.
But that's not a complication, it's just precisely what we're saying B2
exists for: to stop that from happening.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
;more pollution/problems get found far from where they really
happened." The generics experience was that few people bothered to use
`checkedCollection()`, and I doubt many added type checks via bytecode
either, and it all worked well enough, buuut there are a few reasons for
that that don't translate to null.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
n't have flat
> Complex yet.
>
But they still get *often-flat* Complex? Sounds like *always-flat* Complex
is the perfect thing to punt on then.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
t;uninitialized values are OK, you get two types, a
> zero-default and a non-default"
> - Non-atomicity is an extra property we can add to B3, to get more
> flattening in exchange for less integrity
> - The use cases for non-atomic B2 are served by non-atomic B3 (when .ref
> is
back on "compound".
> The other solution is instead of saying that it's non-terable by default,
> is to force users to always use a keyword to indicate the "atomiciy" state,
>
(I think that would be extremely unfortunate, though.)
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
le uniformity in how things work. I hope it goes this way.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
l" projections.
>
Note I think we should only invoke the concept of "projection" once we get
into type variables. Otherwise we simply have two types for one class. (And
the reason for that is very solid / easy to defend, just by appealing to
how we'd've preferred int and Integer had worked.) I would just call them
the reference type and the (name debated just above) type, simple as that.
> Let's start with _terms_, not _declaration syntax_.
>
Yes, and even the term we like 2nd best for a thing can still be useful in
the documentation of that thing.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
On Wed, Apr 27, 2022 at 9:36 PM Kevin Bourrillion wrote:
(Type R) e.g. Rational, EmployeeId: the default value is illegal; can't
> even construct it on purpose. Every method on it *should* call
> `checkValid()` first. Might as well repurpose it as a pseudo-null. Bugs
> could be prevente
-capable versions of
`Arrays.fill()` and `Arrays.setAll()` which accept a size instead of a
premade array. Actually, if the new Arrays.fill() could short-circuit when
passed `TheType.default` then we might want to do this for types C and O
too; why not make users be explicit.
--
Kevin Bourrillion
now that there are two Class instances for that same
class, so it doesn't explain which one they'd get.
But actually I am increasingly convinced that this method shouldn't return
anything. If it must exist, it should just throw, because its purpose is to
get an object's dynamic type, and there is
hen
Integer changes buckets anyway. So... just the users saying "we should get
to use `==` as a shortcut for `.equals()` as long as we stay within the
cached range"? Oh, wait:
Within these constraints, there are reasonable things that can be done with
> '==', like optimizing for a situation
On Tue, Apr 26, 2022 at 5:11 PM Kevin Bourrillion wrote:
Nice question! I thought about it a little bit and this is my own first
> take. I think *most* of the advice would be cross-cutting across param
> types, return types, field types, etc.:
>
> If
> 1. I don't want null
ex.val(1, 2);
>
The criteria above seem to say that a constructor should always return the
value type (with no need for `new Foo.val`). And good thing, because that's
the way that lets you easily store it into either kind of variable. Yay?
>
> On Tue, Apr 26, 2022 at 1:56 PM Dan Smith wrote:
> &g
orse (on either performance or syntactic grounds) than Java?
>
I think I would insist that `.val` be spelled with only one additional
character... or even that the value type be generated as the snake_case
form of the name!
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
nly work for
> identity types. Then in time `==` could be reintroduced as a synonym for
> `Object.equals()` and everyone would be happy and write shiny bug-free
> programs I know this would be a large deal. Sometime I will have to
> write at length about just how bad the problem of identity-equality
> overuse/abuse has been.)
>
> --
> Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
>
>
>
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
n in time `==` could be reintroduced as a synonym for
`Object.equals()` and everyone would be happy and write shiny bug-free
programs I know this would be a large deal. Sometime I will have to
write at length about just how bad the problem of identity-equality
overuse/abuse has been.)
--
Kevi
fficient?
>
Well, the thing forcing our hand in our case is the need to work within the
limitations of a language with 28 years of expectations already rooted in
brains. That is what says we need Foo/Foo.val. So your thought experiment
is sort of a false equivalence; the same argument for Foo/Foo.
ets to choose whether the value type (if B3) exists at all or
(if B2) does not. The use-site then either (if B3) has a choice of which
type to use, or (if B2) has no choice.
Many of the responses seem to just be overlooking or misunderstanding this
distinction. I'm sorry if I wasn't being clear.
--
Ke
On Mon, Apr 25, 2022 at 2:47 PM Dan Heidinga wrote:
As I said above, migration is one use case.
It's also only one of the 8 reasons I wrote up. 9 with Brian's.
Do we want to make this worse to read for the migration use case?
>
Yes, and for 8 other reasons!
--
Kevin Bourrillion | J
ld be the way to make it look and work just like int/Integer. I can
at least _imagine_ this being a recommended convention.
(But we have to have a separate conversation on how useful typealiases
could be if done right!)
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
wearing
its history on its sleeve. It's a good outcome in perpetuity imho.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
till values, but I certainly don't mean to
imply we'd ever want a value that's 1000 bytes long. Upon looking at it
again, this text just seemed unnecessary and so I've nuked it.
> On Fri, Apr 22, 2022 at 6:38 PM Kevin Bourrillion
> wrote:
> >
> > I'd like to remind everyone abou
uot; have to retrain them on this. And as I'll keep
repeating, we can't escape this need for retraining no matter which way we
go. I think the story is to a point now where the retraining won't
be *nearly* as hard as it once was.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
that
what would normally be called `Integer` gets called `int` and what normally
gets called `Integer.ref` or maybe `int.ref` gets called `Integer` ... that
is much stranger.
What are the opposing arguments?
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
mposite(compound) --> an int was
never an object and it still isn't --> so neither are my value types"
(Of course, I'm still on the path that we *want* users to lean on their
existing understanding of int-vs.-Integer for understanding
MyType.val-vs.-MyType.ref, which I know has been controve
kind of subtyping people know and the only kind
they *should* think of is polymorphic subtyping.) They should continue to
think of "A is a subtype of B" as meaning that they can interact with a B
that is actually itself really an A; it's what Integer (but not int) gives
you. This relationship is ca
nt to say "the int value 5 is an object now too", then we
have some problems:
* I think it ruins those clean explanations just given
* we'd need to coin some new term to mean exactly what I've just proposed
that "object" mean, and I have no idea what that would be (do you?)
Wh
On Fri, Apr 1, 2022 at 7:28 AM Remi Forax wrote:
It is too magic for me, especially because
> new Object().getClass() != Object.class
>
Sounds
* not weird enough to rule out, but
* weird enough to "deprecate" `new Object()` and make Object abstract
So either way, I'd still really want for `new Object()` to get a warning,
and for Object to eventually become literally abstract (how long from now,
I don't as much care). Why: the fact that Object isn't abstract actually
detracts from people's understanding of both abstractness and Object. By
On Wed, Jan 26, 2022 at 5:14 PM John Rose wrote:
> A. I am aiming for new Object().getClass() == Object.class.
>
That you can do `new Object()` at all looks like the proverbial bathwater
here.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
won't be broken. (We've found a
> significant number of these problems in our own code/tests, FWIW.) No new
> static types means inference results won't change.
>
Seems less "breaking compatibility" than just "Hyrum's Law". But I lack
understanding of how widespread or hard to fix these problems are. We could
maybe do an experiment over here if necessary.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
.
On Thu, Feb 24, 2022 at 7:40 AM Dan Heidinga wrote:
The rest of this is more of a language design question than a VM one.
> The `Foo()` (without a new) is a good starting point for a canonical
> factory model.
It's been mentioned somewhere in all this that there *can* be a static
method wit
ass that
> carries a double but fits in one slot.
>
But... to be clear... it *is *also intentional implementation detail,
right? In the programming model a user can't care about the distinction?
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
nce type.
>
> I realize that much of this could potentially change—reflection story,
> terminology, etc. But consider this the "plan of record" for now.
>
> https://bugs.openjdk.java.net/browse/JDK-8259731
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
to act as the reference when using a Value
> key in a WHM.
> This is basically the solution we rejected for WeakReference
> and all the same problems apply here. It may allow existing code to
> "keep working" when it first deals with Values but introduces strange
> failure cases and difficult to reason about rules. It avoids
> exceptions but leaves the code doing the wrong thing with no way to
> tell.
>
> Anyone see another option here?
>
> --Dan
>
>
>
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
Can't attend today, but
On Wed, Jan 12, 2022 at 8:08 AM Dan Smith wrote:
"We have to talk about 'primitive'": terminology discussion regarding the
> word "primitive"
>
I'm planning to continue this conversation on-thread, so no worries for now.
--
Kevin Bo
Really appreciate the attention and insight here. I must respond on the
installment plan.
On Wed, Dec 15, 2021 at 7:15 PM John Rose wrote:
> On 15 Dec 2021, at 10:42, Kevin Bourrillion wrote:
>
> …
> The main problem I think we can't escape is that we'll still need some
> wo
. They still need the word "pear"
sometimes.
Contrast: traveler says "here, these are pears."
"What?"
"These are the apple kind of pears, and what you have are heritage pears."
For a while no one knows what the hell "bring me a pear" means anymore.
Also, for some reason everyone is being chased by a giant spherical boulder.
One feels more destabilizing than the other.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
f writing a class, where expectations have to be
weakened.
I think what you're saying here, at root, is to give the "value" name to
> extended primitives, and find another name to give to B2?
>
Yes, that's somewhere near the end of my message. I think B2 should stay
centered on the concept of identitylessness.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
want people to call bucket 1 classes "identity classes", don't we?
Footnote: for a more concrete manifestation of this problem: I am sure we
cannot possibly get away with Class.isPrimitive() being true for these
classes. Right?
Thoughts?
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
se they scale things! This would be more similar to
a one-dimensional vector space than to a scalar imho the best
adjective for today's primitives is "primitive" and I'll plead my case
about that soon too. :-)
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
ill try to examine various options
for adjusting that particular model to accommodate Valhalla.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
reasons why", it works and I suspect most users wouldn't
even click.
Does that make perfect sense? Again, the thread just backed into the topic
sideways.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
On Wed, Nov 3, 2021 at 12:43 PM Brian Goetz wrote:
>
> On 11/3/2021 3:00 PM, Kevin Bourrillion wrote:
>
> Okay, let's stick a pin in proper-value-types (i.e. try to leave them out
> of this discussion) for a moment...
>
> One question is whether the existing design fo
On Thu, Nov 4, 2021 at 9:28 AM Dan Smith wrote:
> On Nov 3, 2021, at 6:19 PM, Kevin Bourrillion wrote:
>
> I think my intuitions about boxes tie heavily to 'getClass' behavior (or
>> some analogous reflective operation). "What are you?" should give me
>> dif
On Thu, Nov 4, 2021 at 7:56 AM Brian Goetz wrote:
On 11/4/2021 2:54 AM, Kevin Bourrillion wrote:
>
> Point.ref pr = pv; // same object… now it’s on the heap, though, with a
>> real live heap header
>> assert pr.getClass() == Point.class; // same class, but...
>>
&g
nt.ref.class, and the method is named “get-class”.
>
If s/named/misnamed/ is it still devastating? :-)
With this my brain has given its last feeble gasp of the night.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
values").
(If preparing to respond that methods on a static type that's final don't
have dynamic dispatch either, meh, that's more simply understood as "of
course you don't actually query when you already know the answer; that's
just optimization". Whereas with the value type, the idea of this querying
at all isn't even a thing.)
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
have to make a careful determination between
which of those associations we deem are the *essential* ones and which are
merely circumstantial or ancillary. And then we want for the essential
portion to change as little as possible with the release of Valhalla. Users
want to feel lots of stable
Certainly possible I'm just misunderstanding something. (I don't *think* I
am...)
On Wed, Nov 3, 2021 at 11:24 AM Dan Smith wrote:
> On Nov 3, 2021, at 11:23 AM, Kevin Bourrillion wrote:
>
> On Wed, Nov 3, 2021 at 9:02 AM John Rose wrote:
>
> > One way to thicken this thin
put us straight back to where this email started.
But this all smells rotten, like it demands we find a simpler way to think
about it (which you may already know, and I'm just missing it so far).
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
ople to swallow (I don't recall if `instanceof`
does or means to support *all* such cases or not).)
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
us, can you spell it out a
bit?
It sounds like a special rule treating Object methods differently from
other supertype methods (?), which would be nice to not need.
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
mentation is consenting to have that identity
"forgotten" at any time just by round-tripping it through some collection
etc.)
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
d, the OG/pure primitive types (B3) are almost
> never used.
>
B2 is certainly the more basic feature, and could at least hypothetically
release earlier than the rest. Regardless of timing, it does seem that the
costs and benefits of B3 need to be interpreted *relative* to B2.
--
Kevin Bou
Hmm, I'd rather pretend I hadn't said it, if that will keep the focus on
the main points. :-)
I haven't caught up on the plans for equality in a long time.
On Tue, Nov 2, 2021 at 3:59 PM John Rose wrote:
> On Nov 2, 2021, at 3:44 PM, Kevin Bourrillion wrote:
>
>
> Btw
Integer relationship (of course, `42.getClass()` is uncommitted
to any precedent).
It seems like `Complex.class` (as opposed to `Complex.ref.class`) would
never be returned by `Object.getClass()` in any other condition than when
you could have just written `Complex.class` anyway.
Actually, that makes
ok good, it's worth
> asking whether we should tackle these use cases at all. But there's a risk
> that developers would misuse classic primitives if we don't provide the
> safer alternative. Could we effectively communicate "you're doing it wrong,
> just use identity"? Not sur
quot; has always meant "there is no instance here",
and if we *do* define "null value", it will mean the same thing!
I think we are better off treating this as a discussion about
> initialization safety, rather than nullity, until we have a clear story of
> how we wa
(well-written code only sees valid values) but blows up in unpredictable
> ways when a bug or a hostile actor leaks into your program. If we
> don't offer stronger guarantees, and your code isn't willing to check for
> , you really shouldn't be programming with a primitive class.
>
Indeed, calling it my second-best was not meant to imply I don't also hate
it. :-)
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
d/array component of that inline type gets augmented with a check that
> rejects reads of the default value (treating it as "you forgot to initialize
> this variable").
>
> That is:
>
> Point p = points[3];
>
> compiles to
>
> point p$0 = points[3];
> if (p$
I feel that it can only make things more confusing to users; that in
fact it will cause a large share of all the confusion they do feel. So
wait, what IS the wrapper class then? What IS this reference projection
then? I see no benefit to blurring that line, at this point.
Reactions?
--
Kevin Bourrillion | Java Librarian | Google, Inc. | kev...@google.com
66 matches
Mail list logo
