Simplify to apply/applyMethod/get

[erights]

See https://github.com/Agoric/eventual-send/issues/41

[hax]

I am not sure whether I understand all the things, but it seems all other things can be achieved by applyMethod and applyMethodSendOnly.

If consider convenience and the syntax (wavy dot or some other possibilities), I will expect get (value = foo~.x) and setSendOnly (foo~.x = value).

It seems very weird to have getSendOnly which do not have real use case so it seems the existence of it may encourage bad practice (use get syntax for side effect). And I can't understand the reason why drop set/setSendOnly in the meetings. foo.x = bar.y = value is always same as bar.y = value; foo.x = value in JS (any exception?), so I expect foo~.x = bar~.y = value should always same as bar~.y = value; foo~.x = value. If someone expected foo~.x will receive a promise returned by bar~.y = value they will have already been caught by foo.x = bar.y = value in various cases. So IMO foo~.x = value (setSendOnly) never introduce any new issue in the language, on the contrary, do not support setSendOnly introduce inconsistency and break the user's expectation. (Yes we do not support a?.b = value now but we may add it in the future as tc39/proposal-optional-chaining#18 .)

Of coz I agree a.b = v = c.d = value is potentially confusing anyway (and even much confusing in destructuring case a = {x, y} = value which many programmers expect a only have x and y properties), but this is the issue which we leave to coding style and linter. ESLint already have https://eslint.org/docs/rules/no-multi-assign , which can be easily extend to wavy-dot syntax.

I also suspect applyFunction/applyFunctionSendOnly. Yes it provide some convenience like get/setSendOnly but its syntax f~.() is weird. In the discussion of optional chaining, many suggested drop f?.() because its syntax is confusing (why function call have any relationship to . notation?) and the use cases is not as stronger as o?.prop and o?.[prop]. I feel these arguments also apply to this proposal.

Even we want to keep applyFunction/applyFunctionSendOnly, we'd better reconsider the syntax for it. For example, f~.invoke() may be a better choice. This option is discussed in optional chaining (f?.invoke()), and denied because of the confusion of this in obj.m?.invoke(). It seems f~.invoke() do not have similar issue.

[erights]

So everyone else has context, the tc39 discussion of the chained assignment anomaly begins at https://www.youtube.com/watch?v=6tzni9p8TWM&list=PLzDw4TTug5O0ywHrOz4VevVTYr6Kj_KtW&t=93 , starting at 1:33.

For the record, the earlier SES discussion I cite is at https://www.youtube.com/watch?v=isi6B3WJ7RQ&list=PLzDw4TTug5O1jzKodRDp3qec8zl88oxGd . I think the chained assignment discussion is early but I have not checked.

@hax I agree that getSendOnly should probably be dropped. I did raise this issue in my talk but equivocated.

I agree that f~.invoke() doesn't suffer from the this-binding problems of f?.invoke(). Nevertheless, given that the optional chaining syntax for optional function invocation is f?.(), wouldn't it be surprising if the syntax for eventual function invocation were anything other than f~.() ?

Btw, at Agoric, we use only eventual get, applyMethod, and applyMethodSendOnly. Because of the way our distributed object layer works, we cannot currently support applyFunction. Frankly, so far, we haven't missed it. Various language-neutral but oo distributed object frameworks like cap'n proto https://capnproto.org/cxxrpc.html have direct analogs of eventual get, applyMethod, and applyMethodSendOnly. I hope that someone maps these onto cap'n proto, though we have no such plans ourselves. There is no such mapping for any of the other operations we're considering.

Do you expect eventual assignment to be useful, or are you arguing just from symmetry and minimizing surprise?

What's your opinion on dropping eventual has and eventual delete?