On 20/10/2020 5:01 pm, Kim Barrett wrote:
On Oct 20, 2020, at 2:09 AM, David Holmes <[email protected]> wrote:
On 20/10/2020 3:26 pm, Kim Barrett wrote:
On Tue, 20 Oct 2020 03:25:45 GMT, Mandy Chung <[email protected]> wrote:
@kimbarrett your reworded text is okay. I think "if it initially had some other
referent value" can be dropped.
For a `Reference` constructed with a `null` referent, we can clarify in the
spec that such reference object will never
get cleared and enqueued. I suggest to file a separate issue to follow up.
I don't think that clause can be dropped, because of explicit clearing (by
clear() or enqueue()) rather than by the
GC. If the reference was constructed with a null referent, ref.refersTo(null)
cannot tell whether ref.clear() has been
called.
I think that can be addressed by considering a Reference created with a null
referent to be immediately cleared.
I think if it’s treated as immediately cleared then it should also be
immediately enqueued. But immediate
Mandy's comment implied that references with a null referent never get
enqueued. Otherwise when would they get enqueued? There would be nothing
to trigger it.
David
-----
enqueue has problems; it can’t be done by the Reference constructor because the
derived constructors
have not yet completed, and exposing the possibly incompletely constructed
object to the queue processor
is problematic. And if it can’t be done by the constructor, it’s not clear who
would do it.
But the more we discuss this the more I think allowing an initial null referent
was a mistake in the first place. :(
I agree, but here we are. Very hard to know what the compatibility impact of
changing that would be.
