On Jan 16, 2018, at 1:08 PM, Jochen Theodorou <blackd...@gmx.org> wrote: > > which is a big deal of a problem if the class, that is supposed to be exposed > to the framework is not under the control of the framework. And there is no > good solution (rewriting the bytecode for example is no good solution)
Yep. We didn't solve all those problems in 9 since they are very complicated trade-offs, and the "new kid on the block" of enforced encapsulation is taking ground previously occupied by the "neighborhood gang" of legitimate frameworks. So we need a way to give those frameworks what they need, in a way that still make encapsulation preservable and checkable. (My mental model for this tradeoff is, how can I AOT-compile as much as possible, while still leaving open some legitimate hooks for frameworks to operate? I.e., enabling AOT and framework intercession at the same time is what winning looks like.) The privateLookup API will allow a framework to get full-power "guest" status in an arbitrary uncooperative class. At least, that's the advertisement. Will that help, or is there some bad fine-print to that API?
