martinblostein

I'll just +1 that this should be fixed. I ran into this as a breaking change while trying to migrate from graphql-iso-date.

Mark, I see you've added some code to parse calls, but I was thinking I'd start working towards a simple working implementation of `j` from the other end. This minimal...

Yes, that's exactly what I envision. What I'm going to implement is just the framework for handling the `j` argument, before any evaluation. However, this will be a good more...

Let me try and sum up to check my understanding: - The top layer (\\_interface) determines the user interface. - The middle layer (table\_proxy) is fixed for all possible implementations....

If we need self-reference and mutability, then I think reference classes might be the most straightforward answer. They are part of base R. If `remote_table_state` was an instance of RefClass...

The reference classes aren't the most efficient, but I don't think this matters because we won't be keeping anything large in the remote state object, which is just part of...

I like it! It allows us to carry on with whatever structure we like, without sacrificing the ability to deal with interfaces that use updates by reference. (I'm not crazy...

> Those two steps could be separate calls to the table_proxy. It would be nice to update only a small part of the remote_table_state in each step to avoid unnecessary...