[
https://issues.apache.org/jira/browse/BEAM-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16484501#comment-16484501
]
Kenneth Knowles edited comment on BEAM-2980 at 5/22/18 8:19 PM:
----------------------------------------------------------------
Hmm, yes it is subtle. I think that we have a minor problem because we don't
clearly distinguish between handles to mutable locations and the immutable
(future) values therein.
I would annotate like so:
{code:java}
BagState<X> myBag = // a handle to a mutable bag
ReadableState<Boolean> isMyBagEmpty = myBag.isEmpty(); // a future value of
isEmpty as of this program location
readResultBefore = myBag.read(); // the contents of the bag at this program
location (empty)
myBag.add(bizzle); // the bag now contains bizzle
readResultAfter = myBag.read(); // the contents of the bag at this program
location (bizzle)
bool createBeforeReadAfter = isMyBagEmpty.read() // the future value from above
{code}
But I don't actually like my answer. I really don't like that BagState
implements ReadableState! We made this terminology up to make it "easier" but
it means that there is no explicit future value for the contents of the bag.
Here is what it would be if we just abandoned ReadableState and went with
StateFuture (deliberately avoiding JDK class names)
{code:java}
BagState<X> myBag = // a handle to a mutable bag
StateFuture<Boolean> isMyBagEmpty = myBag.isEmpty(); // a future value of
isEmpty as of this program location
StateFuture<Iterable<X>> contentsFuture = myBag.conents(); // an immutable
future value as of this program location
myBag.add(bizzle); // the bag now contains bizzle
readResultBefore = contentsFuture.get(); // the resolved future value (empty)
readResultAfter = myBag.contents().get(); // the actual contents of the bag at
this program location (bizzle)
bool createBeforeReadAfter = isMyBagEmpty.get() // the future value from above
(true, it is empty)
{code}
And to be honest, I think this latter API will now be familiar to a lot of
users. Of course, usual future-oriented programming practice is "never call
get" but "always chain a callback" style. I think we could be forgiven for not
doing that, since the point of the futures is more batching than async.
was (Author: kenn):
Hmm, yes it is subtle. I think that we have a minor problem because we don't
clearly distinguish between handles to mutable locations and the immutable
(future) values therein.
I would annotate like so:
{code:java}
BagState<X> myBag = // a handle to a mutable bag
ReadableState<Boolean> isMyBagEmpty = myBag.isEmpty(); // a future value of
isEmpty as of this program location
readResultBefore = myBag.read(); // the contents of the bag at this program
location (empty)
myBag.add(bizzle); // the bag now contains bizzle
readResultAfter = myBag.read(); // the contents of the bag at this program
location (bizzle)
bool createBeforeReadAfter = isMyBagEmpty.read() // the future value from above
{code}
But I don't actually like my answer. I really don't like that BagState
implements ReadableState! We made this terminology up to make it "easier" but
it means that there is no explicit future value for the contents of the bag.
Here is what it would be if we just abandoned ReadableState and went with
StateFuture (deliberately avoiding JDK class names)
{code:java}
BagState<X> myBag = // a handle to a mutable bag
StateFuture<Boolean> isMyBagEmpty = myBag.isEmpty(); // a future value of
isEmpty as of this program location
StateFuture<Iterable<X>> contentsFuture = myBag.conents(); // an immutable
future value as of this program location
myBag.add(bizzle); // the bag now contains bizzle
readResultBefore = contentsFuture.read(); // the resolved future value (empty)
readResultAfter = myBag.contents().read(); // the actual contents of the bag at
this program location (bizzle)
bool createBeforeReadAfter = isMyBagEmpty.read() // the future value from above
(true, it is empty)
{code}
> BagState.isEmpty needs a tighter spec
> -------------------------------------
>
> Key: BEAM-2980
> URL: https://issues.apache.org/jira/browse/BEAM-2980
> Project: Beam
> Issue Type: Bug
> Components: beam-model
> Reporter: Kenneth Knowles
> Assignee: Daniel Mills
> Priority: Major
>
> Consider the following:
> {code}
> BagState<X> myBag = // empty
> ReadableState<Boolean> isMyBagEmpty = myBag.isEmpty();
> myBag.add(bizzle);
> bool empty = isMyBagEmpty.read();
> {code}
> Should {{empty}} be true or false? We need a consistent answer, across all
> kinds of state, when snapshots are required.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
