Valhalla EG minutes 6/21/17

Karen Kinnear karen.kinnear at
Tue Jul 11 21:42:59 UTC 2017


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


> On Jul 5, 2017, at 2:43 PM, John Rose <john.r.rose at> wrote:
> On Jul 5, 2017, at 11:39 AM, Paul Sandoz <paul.sandoz at <mailto:paul.sandoz at>> 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

More information about the valhalla-spec-observers mailing list