Paul, We are working hard on getting the nest mates requirements clarified. I would like to use that to support the Lookup.defineClass and not do a Quick&Dirty in advance for MVT . I think we should stick with the reduced restrictions for withfield for early access. I think we should put our energy into getting nest mates and Lookup.defineClass ready.
We have three parts to Lookup.defineClass. 1) PRIVATE mode handling - which we believe we can support with nest mates - we do not want to do any versions of this based on unsafe.DAC current behavior, - we are looking at cleaner behavior for nestmates 2) “temporary” name - i.e. find doesn’t work 3) CP patching/user data My mental model is that we don’t have to add all of these at the same time, although we will want user feedback on when to remove unsafe.DefineAnonymousClass. In fact, we would love more examples of current use cases, to help guide our design. thanks, Karen > On Jul 5, 2017, at 2:43 PM, John Rose <john.r.r...@oracle.com> wrote: > > On Jul 5, 2017, at 11:39 AM, Paul Sandoz <paul.san...@oracle.com > <mailto:paul.san...@oracle.com>> wrote: >> >> >> I was unsure if we require a new method L.defineAnonClass or could leverage >> the existing L.defineClass. IIUC for expediency the current hooks in the VM >> lean towards anon classes, since there is already code to defer to the host >> class, whereas the general defineClass case will likely require more work, >> although i can potentially see some short cuts if we focus on VCC/DVT. >> > > Good point. Yes, that part isn't designed yet. It may manifest as an extra > argument or two to the L.dC. > > At least two degrees of freedom apply there: 1. suppressing the name (no > system dictionary update), > 2. providing some sort of "user data" to bind to the class (can be a single > ref., replaces CP patching). > > For MVT we can just generate a throwaway name, like DVT.getName()+":29348". > > — John
