fix: replace openDetail with quoting q

[erights]

This combines the declassification of openDetail with the quoting of the q from @kriskowal's assertion style. It makes sense that if you're putting the quoted form of the stringified payload into the message, then you must declassify it anyway, so it is unsurprising.

Open question: @kriskowal just did a JSON.stringify directly, without doing a toString stringification first. This has pros and cons. Looking for feedback.

[erights]

I just changed my mind and revised it to JSON.stringify without first doing toString. But question still open. Still looking for feedback.

[kriskowal]

I like the idea of renaming openDetail to q and for it to be the more general form of what I’ve been doing with q in SES strictly for string details.

To account for cycles in the JSON representation of a detail, we might be able to use a JSON reviver and replace cycles with ibid references. The Node.js utils built-in module exports the function it uses for representing objects with console.log, but I hesitate to use a built-in module for anything that might also be used on the web.

[kriskowal]

I believe this will throw RangeError for payloads that contain cyclic graphs.

[erights]

You meant a JSON replacer, right?

[kriskowal]

Indeed!

[erights]

@kriskowal I did not intend to hit the "request rereview" button just now. I will do so on purpose soon, but not yet.

[erights]

@kriskowal , future possibilities to keep vaguely in mind while reviewing:

Moving this assert package into SES-shim, replacing the assert module there.

If we make SES-shim depend on Jessie for what SES and Jessie have in common, then we might want to move this assert package there instead. (attn @michaelfig )

I expect this this assert package will eventually be coupled to our error-stack shim and a console emulator, so the substitution values can be recovered from the other "side" of the console for debugging purposes. Also to keep in mind when we examine other logging possibilities. (attn @warner )

This assert package indicates failure by throwing an error. This is appropriate for failures

• that our caller should be able to react to and recover from.

We need a way to indicate that, instead,

• this turn-or-crank should be aborted and the vat should regress back to the last consistent state. (attn @dtribble )
• this vat is confused and should be permanently terminated.

The error that's thrown is always a direct instance of Error. We should have some way, perhaps in the details part of the API, to indicate which specific error constructor to use.

[kriskowal]

The ibid replacer seems fine.

nit: I do love Latinisms like /ibid/, but for clarity to the folks who would have to look it up, I favor the name “seen”. I’ve worked with majority-ESL teams that have even convinced me that “indexes” is better than “indices”.