git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] Inconsistency in Handle based APIs - Specifically "close"


It is not a blocker for me.

But if we want consistency, either applying pattern "asyncXYZ()" or
"xyzAsync()" for async operations works for me.

- Sijie


On Mon, Mar 19, 2018 at 4:20 AM, Ivan Kelly <ivank@xxxxxxxxxx> wrote:

> Hi folks,
>
> I'm currently changing some parts of pulsar to use the new APIs and
> the inconsistency in the close api has raised its head again, so I'm
> restarting this discussion.
>
> Handle has the following methods:
> async: asyncClose
> sync: close, getId, getLedgerMetadata
>
> ReadHandle has the following methods:
> async: read, readUnconfirmed, readLastAddConfirmed,
> tryReadLastAddConfirmed, readLastAddConfirmedAndEntry
> sync: isClosed, getLength, getLastAddConfirmed
>
> WriteHandle has the following methods:
> async: append
> sync: getLastAddPushed
>
> Close is inconsistent with the rest of the methods for a number of reasons.
> 1. No other async method uses the async* pattern.
> 2. All other sync methods are querying local data and are sideeffect
> free. Close can trigger I/O.
> 3. Each other method has one way be being called, close has two.
>
> I'm not going to suggest a solution to this right now, but any
> solution which gets rid of this inconsistency would be acceptable.
>
> New APIs shouldn't have inconsistencies like this from the outset, and
> this is a blocker for me for moving the API away from the Unstable
> annotations.
>
> What are your thoughts?
>
> Cheers,
> Ivan
>