Ian Denhardt
Ian Denhardt
Quoting Ross Light (2017-03-15 18:52:42) > Right, but that means that you can make a backwards-compatible change > in your schema and break call sites. That seems not ideal. It's...
@zombiezen, what do you think of using a builder? e.g: ```go remoteObj.Method().Foo("Hello").Bar("World").Call_(ctx) ``` I could actually see this scaling up to replace most of the current struct manipulation, but that's...
I started toying around with a builder-oriented API just to experiment, partial changes here: https://github.com/zenhack/go-capnproto2/commit/cf5f363a07c8f87f444615f72deb3f4fe3828187 The builder-style methods aren't very different in size than the existing ones -- just an...
@zombiezen, curious to hear what the problems you encountered were in more detail -- they're not obvious to me at all.
The point about breaking use of interfaces is a good one; hadn't thought of that. The other trouble with the earlier idea is it's not clear to me how (or...
I've been thinking about some of this again lately. Question regarding the existing design: what's the point of the callback? As opposed to following the C++ library's design and having...
Quoting Ross Light (2019-12-20 11:18:24) > The C++ implementation uses this to reuse arena memory between > individual RPCs, something that's desirable for the Go implementation > as well. Aha,...
Coming back to this, re the idea of doing: ```go req := remoteObj.MethodRequest() req.SetFoo("Hello") req.SetBar("World") req.Send_(ctx) ``` Rather than have a separate `.Close()`/`.Release()` on the request, we could just have...
Good point about the error handling -- though putting it in a callback doesn't force you to check errors from setters either; it's kindof a separable issue, but it's *really*...
(It would probably still be a good idea to have an explicit release operator)