refactor: get passStyleOf from VataData if there

[erights]

See Agoric/agoric-sdk#8051

If there is already a VataData global containing a function named passStyleOf, then presumably it was endowed for us by liveslots, so we should use and export that one instead.

[kriskowal]

I think I would only suggest considering whether VatData is the right namespace. I assume that it will be equally compelling to endow passStyleOf into caplets.

[kriskowal]

This might be an opportunity to christen the Ocap namespace as suggested by @weizman, with the caveat that would imply the existence of different %Ocap% and %SharedOcap% namespace objects, since Ocap.lockdown() would not be visible in compartments.

[mhofman]

Haven't reviewed yet. I know that VatData is used in this fashion already, but I believe only within agoric-sdk. I'm actually wondering if we need to namespace passStyleOf for now, or can get away without until we figure out the broader Endo / SES namespacing issue.

[mhofman]

Why put this check inside the maker instead of the actual passStyleOf exported below? I know it'd become a less readable ternary, but it just feels strange to have a maker return a preexisting value, ignoring it's parameter.

[kriskowal]

I will not be bothered if this becomes a cascade of the two namespaces whatever they will be in time. It would be a very small scar.

[erights]

I know it'd become a less readable ternary,

It wasn't bad. Done.

[erights]

I assume that it will be equally compelling to endow passStyleOf into caplets.

Not really. The strong motivation comes from running user code in an on-chain virtualized environment, where the user's WeakMap would have been replaced with one that prevents the sensing of garbage collection on behalf of virtual objects.

This make the motivating use so narrow that I'm gonna go ahead with the current name, for the sake of lower friction integration with agoric-adk.

[gibson042]

AFAICT, this is the only mention of VatData in all of endo, and one of only two non-spurious references to liveslots (the others looking like migration cruft). If fundamental modules are going to defer to their environment, it would be good to establish an endo convention supporting that while keeping it independent rather than inverting the usual dependency direction with agoric-sdk. My first thought would be Symbol-keyed properties, e.g.

Suggested change

	globalThis?.VatData?.passStyleOf ||
	globalThis?.[Symbol.for('@endo passStyleOf')] ||