[jira] [Comment Edited] (BEAM-2980) BagState.isEmpty needs a tighter spec

["Kenneth Knowles (JIRA)" <ji...@apache.org>]

    [ 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)