Reference-default style

[Dan Smith]

> On Dec 20, 2019, at 1:04 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> I don't want to force clients to have to keep a mental database of "what is the inline flavor of this called."

> to the extent ref-default is common, the client now has to maintain a mental database of the polarity of every inline class

> From a user perspective, we are introducing _two_ new kinds of top level abstractions; in (2), we are introducing one, and leaning on interfaces/abstract classes for the other.


> (Think about how many brain cycles you've spent being even mildly miffed that the box for `long` is `Long` but the box for `char` is `Character`.  If it's more than zero, that's a waste of cycles.)

I think you're trying to have it both ways.

Is the story for (2) that there are two declarations, an interface and an inline class, that clients will think of as distinct entities? Or is the story that there is one entity, the pair of types, with one name for both of them?

Once your mental database is keyed on a single name, associated with two different types, it feels like you're doing the latter. But if that's the case, then you need a "polarity" column in the database.

I guess I'm saying I'm not sure you can get away with only one name while expecting clients to buy that it's "just" an interface. "Interface that has a matching inline class" *is* a new kind of abstraction.

> if the polarity is not effectively a forced move (as in (2), where we only use it for migration)

>    On the other other hand, having more ref-default classes than the migrated ones will make `.inline` stick out less.

One of the points I'm trying to make in this mail is that reference-default use cases are going to exist everywhere, no matter what language choices we make. It's something useful people will do, whatever tools we give them.

I suppose options (3)-(5) will encourage the style more, so there will be more of them, but (1) and (2) aren't going to be able to contain it to "only for migration".

>> (5) feels like something fundamentally new in Java, although if you squint it's "just" a variation on name resolution. What originally prompted this idea was seeing a similar approach in attempts to introduce nullability type operators—legacy code has the "wrong" default, so you need some lightweight way to pick a different default.
> (5) could be achieved with another long-standing requests, aliased imports:
> 
>     import Foo.inline as Foo;
> 
> Not saying that makes it better, but a lot of people sort of want import to work this way anyway.

Yep.

And I think something like this may be in our future, but something we have to decide is whether we're comfortable with two different compilation units interacting with each other but spelling the same type two different ways.