> De: "John Rose" <[email protected]> > À: "daniel smith" <[email protected]> > Cc: "amber-spec-experts" <[email protected]>, "joe darcy" > <[email protected]> > Envoyé: Samedi 9 Mai 2020 22:15:07 > Objet: Re: getPermittedSubclasses() on j.l.rClass returning an array of > ClassDesc
> On May 9, 2020, at 12:59 PM, Dan Smith < [ mailto:[email protected] | > [email protected] ] > wrote: >> maybe a better long-term path to getting to a less brittle API is to design a >> new, lower-level API, rather than trying to slowly introduce a new way of >> doing >> things into java.lang.Class. > Yes, that was my thought also. Probably because such an API > is also needed in the design of template classes, at least as currently > envisioned: A bootstrap method for expanding a template species > will inevitably need deep access into the “pieces and parts” of the > template class it is expanding, and those bits will be in symbolic > form (or lower-level things), not resolved. > This BTW is one of many reasons we want a symbolic linkage mode > for indy and condy, in which the BSM is set to run on pre-resolved > ConstantDesc data. I think it's worst, you want some type arguments to be already resolved and some not yet to be resolved. > Class::getNestMembers does something odd, by providing a way > to visit related classes without a separate access check. If a nest > has public and non-public members, you can use a public class > to visit non-public related classes. The permitted-subs accessor > is similar, but permitted-subs have more variability; they can > be in different packages, etc. This means it is more likely that > a permitted-sub will have lesser access than the top class. > Here’s something very ugly we could do, FTR. (I’m not > fully comfortable with any of these choices.) Make the > new accessor @CallerSensitive (like Class::forName) and > have it check accessibility. If it throws, it throws away > any partial information that might have been available. > That’s how Core Reflection rolls. Yesterday, i was thinking exactly the same thing, I decide that it doesn't worth it because usually implementation classes leaks because getClass() is not caller sensitive. > Or leave it as it is, and allow leakage of inaccessible types, > throwing only if types are truly non-existent. Trying to > filter results (to return partial info) is IMO a chase after > diminishing returns. > — John Rémi
