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 <iv...@apache.org> 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 >
