On Dec 16, 2020, at 11:00 AM, Dan Smith <[email protected]> wrote: > > Rémi raised some questions about our story for int vs. Integer vs. legacy > uses of 'new Integer'—how many implementation classes are there? (should we > use species?); what does reflection look like? We agreed it still needs some > polishing.
Here’s what I *hope* we can do, if/when we figure out how to make an abstract class a super of *both* p-class and i-class. And, then, if/when we figure out how to endow a class with both p-class factories and i-class constructors. (See discussion about Enum, which has a similar problem.) (Caveat: I think these are technically feasible but they might turn out to be too expensive to carry out, compared with other technical goals. We might back off to some less elegant solution with sealed hierarchies and multiple types. But I can hope.) At that point we can give jl.Integer both kinds of constructors, and allow it to instantiate both kinds of instances. How could that be possible? Well, suppose specialization is not a purely VM-level activity, but (as seems likely) defers partially to a user-supplied bootstrap method, which decides what’s in any given species of a class. Next, suppose that the BSM is given the choice (for a suitably declared specializable class) to make species *of both kinds*. Finally, declare Integer that way, and make its BSM choose a legacy i-species along some paths, and a new p-species along the preferred paths. At least as a formal possibility, this tactic suggests that the extra degrees of freedom required could be confined into *one class* (Integer) and managed using species distinctions. Being able to do this is clearly not a primary goal of any reasonable specialization story, but it could turn out to be low-hanging fruit, if we are lucky. Hence my hope. — John
