Add a GET_INTERFACE_GUARD meta method to all exo/far objects.

[erights]

See https://github.com/endojs/endo/pull/1809#discussion_r1376929120

Currently, before https://github.com/endojs/endo/pull/1809 and possibly after (depending on the resolution of the conversation linked above), only exo objects declared with an explicit interfaceGuard get an additional GET_INTERFACE_GUARD meta-method added to their behavior. As @michaelfig observes there, this creates an unpleasant sniffing burden on clients. Further, even in that case, if the user-supplied interfaceGuard has a defaultGuards argument other than undefined, the exo/far object may still have actual methods that cannot be discovered by looking at the returned interface guard.

The best repair would be to return a constructed interface guard in all cases that accurately describes all the methods on the actual exo/far object

• including all those implicitly covered by defaultGuards
• including GET_INTERFACE_GUARD itself
• including when no interfaceGuard was explicitly provided
• including in the thisless case, i.e., the case of virtual/durable objects defined using the deprecated kinds API without an explicit interface

For extra credit

• including objects simply declared with Far as the @endo/pass-style level of abstraction. Doing so would require violating the current layering since guards do not even appear until the @endo/patterns level of abstraction. However, without doing so, users are still left with the above sniffing burden.

[kriskowal]

@erights Am I right that this work is completed?

[erights]

@erights Am I right that this work is completed?

Yes, but differently from the issue's description. See

https://github.com/endojs/endo/blob/master/packages/exo/README.md

and

https://github.com/endojs/endo/blob/4c67fe2cbcfd2737cb389b3fb0e358f4eed58af0/packages/pass-style/src/make-far.js#L132-L146

Thus, closing. Thanks!

[erights]

Closed by https://github.com/endojs/endo/pull/1809