Great idea to bring it to dev@. I think it is better to focus here than long doc comment threads.
I had strong opinions that I think were a bit confused and wrong. Sorry for that. I stated this position: - XYZState class is a handle to a mutable location - its methods like isEmpty() or contents() should return immutable future values (implicitly means their contents are semantically frozen when they are created) - the fact that you created the future is a hint that all necessary fetching/computation should be kicked off - later forced with get() - when it was designed, pure async style was not a viable option I see now that the actual position of some of its original designers is: - XYZState class is a view on a mutable location - its methods return new views on that mutable location - calling readLater() is a hint that some fetching/computation should be kicked off - later read() will combine whatever readLater() did with additional local info to give the current value - async style not applicable nor desirable as per Beam's focus on naive straight-line coding + autoscaling These are both internally consistent I think. In fact, I like the second perspective better than the one I have been promoting. There are some weaknesses: readLater() is pretty tightly coupled to a particular implementation style, and futures are decades old so you can get good APIs and performance without inventing anything. But I still like the non-future version a little better. Kenn On Wed, May 23, 2018 at 4:05 PM Charles Chen <c...@google.com> wrote: > During the design of the Beam Python State API, we noticed some > transactionality inconsistencies in the existing Beam Java State API (these > are the unresolved bugs BEAM-2980 > <https://issues.apache.org/jira/browse/BEAM-2980> and BEAM-2975 > <https://issues.apache.org/jira/browse/BEAM-2975>). We are therefore > having a discussion about this API which can have implications for its > future development in all Beam languages: > https://docs.google.com/document/d/1GadEkAmtbJQjmqiqfSzGw3b66TKerm8tyn6TK4blAys/edit#heading=h.ofyl9jspiz3b > > If you have an opinion on the possible design approaches, it would be very > helpful to bring up in the doc or on this thread. Thanks! > > Best, > Charles >
