Hi Karen, Thanks, i understand the need for being conservative here in case we get things wrong. The pragmatic relaxation is entirely reasonable, although i would still prefer to go through a lookup mechanism if we could pull it off :-)
Paul. > On 11 Jul 2017, at 14:42, Karen Kinnear <[email protected]> wrote: > > 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 <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Jul 5, 2017, at 11:39 AM, Paul Sandoz <[email protected] >> <mailto:[email protected]>> 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 >
