all pass-by-reference objects must be marked with Far

[warner]

What is the Problem Being Solved?

#2018 was split up into two pieces. The original ticket remains concentrated on making empty (hardened) objects be pass-by-copy instead of pass-by-reference.

This new ticket is about making all pass-by-reference objects as Far (or Remotable). Once complete, marshal will throw an error if you attempt to serialize a hardened object with Function properties that is not marked with Far/Remotable. The classification code (passStyleOf) will change from:

• use the nature of the object's properties to decide on which category is used (pass-by-copy vs pass-by-reference)
• assert that pass-by-copy has no functions, assert that pass-by-reference has no non-functions

to:

• use getInterfaceOf to decide whether we use pass-by-reference or pass-by-copy, which means only Far/Remotable-marked objects are pass-by-reference, and everything else is pass-by-copy
• assert that pass-by-copy has no functions
• for now, assert that pass-by-reference has no non-functions, but add (immutable) auxiliary data to Presences? #2069 will add auxdata and remove this prohibition

We've marked a lot of Far objects already, and I have a batch of local changes to the dapp repos with some more to come. To find them all:

• uncomment the marshal.js lines that emit a warning and/or throw an error, at the end of the case 'object' clause of passStyleOf(), currently around line 479.
• run tests, add Far until they pass quietly, coming up with a plausible interfaceName for each
• once complete, change passStyleOf() to remove the tail case assertRemotable(val); return REMOTE_STYLE, and change isPassByCopyRecord to become assertPassByCopyRecord

Test Plan

A few test-marshal.js cases will change: unmarked Function-bearing objects must be marked as Far/Remotable, whereas previously only empty objects needed such marking.

Compatibility Issues

I believe we have consensus that this is a good approach, but it's pretty wide-ranging, and takes us further away from the E ideals of everything-is-an-object. So I'd like @dtribble @erights @katelynsills @Chris-Hibbert to confirm that we're willing to require all authors of contracts and vat code to declare all of their pass-by-reference objects with Far/Remotable.

cc @tyg since this needs to be part of the developer guidelines, if it isn't already

[warner]

I'll assign this to the four people from whom I want confirmation: feel free to unassign yourselves once you've commented your approval for the plan.

[katelynsills]

Just to confirm my understanding: The requirement for developers writing Zoe contracts is that they must mark objects with Far that are sent outside the contract (e.g. to the user) and which either 1) have methods or are 2) otherwise intended to be presences (e.g. handles). Empty objects intended to be transmitted as Data no longer need to marked. Objects that stay within the contract vat, such as those that aren't sent anywhere, or are sent to ZCF (same vat), don't need to be marked with Far, but since it doesn't hurt, we should recommend it since it makes the rules of using Far easier. Is this right?

I think with documentation we are ready to enforce this. I can help with any errors that come up.

[Chris-Hibbert]

I was going to ask a variation of the same question. Unmarked objects within a vat will continue to function, and their methods can be called.

Should we have a variant of Far (e.g. Near?) that declares a type for debugging purposes, but doesn't imply that it's intended to be shared outside the vat?

[erights]

Should we have a variant of Far (e.g. Near?) that declares a type for debugging purposes, but doesn't imply that it's intended to be shared outside the vat?

My sense is no. Just mark those as Far. Mostly doesn't hurt.

[erights]

This plan LGTM.

confirm that we're willing to require all authors of contracts and vat code to declare all of their pass-by-reference objects with Far/Remotable.

confirmed.

[erights]

This is the only remaining item to close #2018, yes?

[katelynsills]

I believe this is complete.