Sounds great and thanks for the conclusion summary.
On Tue, Jun 5, 2018 at 4:56 PM Charles Chen wrote:
> Thanks everyone for commenting and contributing to the discussion. There
> appears to be enough consensus on these points to start an initial
> implementation. Specifically, I'd like to hig
Thanks everyone for commenting and contributing to the discussion. There
appears to be enough consensus on these points to start an initial
implementation. Specifically, I'd like to highlight from the doc (
https://docs.google.com/document/d/1GadEkAmtbJQjmqiqfSzGw3b66TKerm8tyn6TK4blAys/edit#headi
Great, I was confused in the description that was provided and then the
follow up by Ben. I think its worthwhile to describe the differences with
actual examples of what happens.
On Fri, May 25, 2018 at 10:54 AM Kenneth Knowles wrote:
> I think the return value of read() should always be an immu
I think the return value of read() should always be an immutable value.
Kenn
On Fri, May 25, 2018 at 10:44 AM Lukasz Cwik wrote:
> Kenn, in the second example where we are creating views whenever read() is
> called, is it that the view's underlying data is immutable. For example:
> Iterable val
Kenn, in the second example where we are creating views whenever read() is
called, is it that the view's underlying data is immutable. For example:
Iterable values = state.read();
state.append("newValue");
If I iterate over values, does values now contain "newValues"?
On Thu, May 24, 2018 at 10:3
I see what you mean but I don't agree that futures imply anything other
than "it is a value that you have to force", with deliberately many
possible implementations. When at the point in 1 and you've got
interface ReadableState {
T read()
}
and you want to improve performance, bot
I think Kenn's second option accurately reflects my memory of the original
intentions:
1. I remember we we considered either using the Future interface or calling
the ReadableState interface a future, and explicitly said "no, future
implies asynchrony and that the value returned by `get` won't cha
Thanks Kenn. I think there are two issues to highlight: (1) the API should
allow for some sort of prefetching / batching / background I/O for state;
and (2) it should be clear what the semantics are for reading (e.g. so we
don't have confusing read after write behavior).
The approach I'm leaning
Thanks for laying this out so well, Kenn. I'm also leaning towards the
second option, despite its drawbacks. (In particular, readLater should not
influence what's returned at read(), it's just a hint.)
On Wed, May 23, 2018 at 4:43 PM Kenneth Knowles wrote:
> Great idea to bring it to dev@. I thi
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
10 matches
Mail list logo
