fix(marshal): reject getters in pass-by-ref, even if it returns a function

[warner]

This doesn't pass the typescript check yet, because it complains that I'm using a (potential) Symbol to do a property lookup:

  const descs = getOwnPropertyDescriptors(val);
  const keys = ownKeys(descs); // enumerable-and-not, string-or-Symbol
  keys.forEach(key => {
    assert(!descs[key].get, X`cannot serialize objects with getters like ${q(String(key))} in ${val}`);
    assert.typeof(
      val[key],
      'function',
      X`cannot serialize objects with non-methods like ${q(
        String(key),
      )} in ${val}`,
    );
  });

But that's exactly what I need to do: I want to reject getters in Symbol-named properties too. I don't need to look at the property name (pass-by-reference doesn't care), so want something that returns key+value tuples like Object.entries().forEach([_key, desc] .., except that Object.entries ignores Symbol-named properties, as does Object.values().

Any ideas how I can appease typescript?

[dckc]

I suggest using entries rather than keys and descs[key]:

  const descs = getOwnPropertyDescriptors(val);
  Object.entries(descs).forEach(([key, desc]) => {
    assert(!desc.get, X`cannot serialize objects with getters like ${q(String(key))} in ${val}`);

[erights]

LGTM

[erights]

I suggest using entries rather than keys and descs[key]:
...

@dckc Using entries was exactly the mistake I made that set us down this long road. What I did not understand is how restrictive entries is. It only enumerates string-named enumerable own properties. It does not enumerate symbol-named own properties.

[erights]

I suggest using entries rather than keys and descs[key]:
...

@dckc Using entries was exactly the mistake I made that set us down this long road. What I did not understand is how restrictive entries is. It only enumerates string-names enumerable own properties. It does not enumerate symbol-named own properties.

The new comments at

agoric-sdk/packages/zoe/src/objArrayConversion.js

Lines 59 to 79 in 97c1bc3

	* Some edge cases to be aware of
	* * If any of the original properties were accessors, `Object.entries`
	* will cause its `getter` to be called and will use the resulting
	* value.
	* * No matter whether the original property was an accessor, writable,
	* or configurable, all the properties of the returned object will be
	* writable, configurable, data properties.
	* * No matter what the original object may have inherited from, and
	* no matter whether it was a special kind of object such as an array,
	* the returned object will always be a plain object inheriting directly
	* from `Object.prototype` and whose state is only these new mapped
	* own properties.
	* * The caller-provided mapping function can map the entry to a new entry
	* with a different key, in which case the new object will have those
	* keys as its property names rather than the original's.
	*
	* Typical usage will be to apply `objectMap` to a pass-by-copy record, i.e.,
	* and object for which `passStyleOf(original) === 'copyRecord'`. For these,
	* none of these edge cases arise. If the mapping does not introduce
	* symbol-named properties, then the result, once hardened, will also be a
	* pass-by-copy record.

is a good example both of how tricky all this is in JavaScript, and how great it is that our pass-by-copy objects avoid these hazards.

[erights]

The changes look good