Despite my initial concerns with the default constructor (primarily
how easily a consumer of a class can find this property), I've come
around to the "public default Complex()" constructor model because it
clearly lets a class's author indicate their intent. The default
constructor should appear as a method in the classfile, though without
a Code_attribute, and should be visible to reflection, etc. It's a
constructor like any other which also acts as a flag to indicate the
author accepts the all-zeros pattern. Expressing this through the
constructor is a clean approach for users and let's us build on
existing infrastructure for representing it - similar to how interface
default methods benefited from being modeled as regular methods.
Right, it's a clear signal at multiple levels -- source, classfile,
reflection -- and this idiom works "well enough" at all of them. And
it's easy to forget the classfile/reflection levels in these discussions.
My misgivings around the term "default" are due to having already used
it to describe interface methods with a default implementation.
Same. It sometimes feels like "reusing keyword disease", but on the
other hand, it mostly works.
The term has also been used related to the default (initial) value of
variables but that has no syntax associated with it. So precedent
supports its use..... a mixed result I guess? ....And I just found a
section in the JLS (8.8.9) that already defines the default
constructor for a class. That's even stronger precedent for reusing
the term here given this is a slightly different kind of default
constructor.
And don't forget annotations...
We've previously talked about allowing value classes to extend
abstract classes. What are the conditions that would allow my value
class to implement a default constructor if it extends an abstract
class? Would the abstract class need a default constructor? No
constructor? (Probing for the edges of this model to see if it breaks
down)
The constructor in a value-capable abstract class is restricted enough
that it should work file here -- no fields, empty constructor body (save
for super() call), and such constraints all the way up to Object.
I really wanted to cram the non-atomic designation on constructors as
well but it's not really a property of the instance; rather it
describes writes to storage which puts it as a property of the class.
Still trying to come up with a better intuition for where this belongs.
One thing we didn't consider completely is a superinterface:
value class Foo implements Terrible { ... }
We had a discussion about "what does non-atomic really mean" at the EG
meeting that I now realize I forgot to write up, so I will try to do
that tomorrow.
