Computed object properties

[michaelfig]

Hi,

I would like some clarification on:

Jessie omits computed property names. Jessie has syntax for mutating only number-named properties, which include integers, floating point, NaN, Infinity, and -Infinity. Jessie omits syntactic support for mutating other property names. Jessie has syntax for computed lookup and mutation of number-named properties, but not other property names.

I don't fully understand why computed string properties are undesirable, or even possible to reject. Does Jessie allow reading computed property names, as in:

let foo = 'abc';
foo += 'd';
if (baz) {
  return bar[foo];
}
bar[foo] = 123;

and if computed properties are disallowed, it is still relatively easy, though tedious, to bypass with confine:

return confine(`bar.${foo}`, {bar});

or even (!):

confine(`bar.${foo} = 123`, {bar});

The reason I ask is that using objects-as-records is painful if there is no simple way to iterate through the properties/values of the object (though I understand why for ... in is rejected). If you intend to disallow this too, I would like to discuss this further, as it is still possible to bypass with a combination of JSON.stringify and confine (exercise left to the reader).

If it's only the mutation you want to prevent, I would suggest whitelisting Object.keys, Object.values, and Object.entries. That would make me much happier.

Indeed, it turns out the only rather bizarre endowment I find passing around (to bond, the Jessie evaluator, and others) is computedGet: (obj, index) => obj[index]. This smells like a missing feature.

Thanks, Michael.

[erights]

I had not considered confine as a way to evade such static vs dynamic restrictions, as long as the string being evaluated is valid Jessie. The mutating example is not.

This is convincing for allowing computed reads. Go ahead and whitelist.

[michaelfig]

Another related question: in your design, what makes bar.abcd = 123 invalid Jessie? Is it because it is not statically proven to be "preparing an object for delivery", or do you intend to reject it in the grammar?

My current grammars fail to parse both:

function doit() { foo[1] = 123; }

and:

function doit() { foo.abcd = 123; }

Syntax error at 25 "=" #0:25 looking for EOL_COMMENT, MULTILINE_COMMENT, callPostOp, callPostOp, memberPostOp, memberPostOp, LEFT_BRACKET, DOT, quasiExpr, QUASI_ALL, QUASI_HEAD, LATER, IDENT, args, LEFT_PAREN, multOp, addOp, shiftOp, eagerOp, relOp, eqOp, bitOp, andThenOp, orElseOp, SEMI

so I'm not so sure of your intentions as to what is statically enforced versus syntactically invalid.

Thanks, Michael.

[michaelfig]

Okay, reading further, I believe those constructs should be accepted by the grammar but the mutation of an dotted identifier should be statically rejected because the target cannot be proven to be a locally initialised object.

[erights]

Y

[erights]

Closed by #26