A class per static field? Why or why not?

[Brian Goetz]

>
>     The approach of companion objects rather than static members
>     provides a useful nudge to thinking of the static parts of a class
>     as being a single, independent entity.
>
>
> Independent entity, yes.  Single, maybe.

Right.  The companion mechanism in Kotlin pushes pretty hard at 
"single"; the companion mechanism in Scala is somewhere in the middle, 
where it use a magic name association between a class called X and an 
object called X, but you can also have objects whose name is separate 
from any class and it can stand as an independent sub-part.  If we went 
down this road, we would probably go even farther, where the analogue of 
`object` would be more like a general-purpose singleton class which you 
could freely mix and match with.  It's not all that different from using 
IODH today from an expressiveness perspective, but (like with enums) it 
moves instance management from the user's side of the ledger to the 
language's side.  Let's say that this is a possibility we could explore 
if we suspected there were a bigger potential payoff.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20221212/6c0103f8/attachment.htm>