qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: ConnectionImpl::getWorkSequence()
Date Tue, 18 Mar 2014 17:14:42 GMT
On Tue, Mar 18, 2014 at 11:43 AM, Clebert Suconic <csuconic@redhat.com>wrote:

> On Mar 18, 2014, at 11:25 AM, Rafael Schloming <rhs@alum.mit.edu> wrote:
> > I doubt there is a good reason, however I suspect the new events API
> would
> > probably be an easier alternative to getWorkHead() and friends.
> > Unfortunately there aren't docs for the Java version of the API yet, but
> it
> > shouldn't be difficult to figure out how to use it from the C API docs.
> >
> I know nothing about the new events API...
> but I think it would be a mistake to have java being an exact mirror of
> the C API. Things like Iterators are pretty common in Java.

I didn't say it was an exact mirror, just that it's close enough that you
should be able to figure it out from the C documentation. I would think
that would be a good thing in general.

As for iterators, in this particular case it's not really C vs Java, it's
the fact that the link/delivery data structure is a linked list, and Java's
collection API doesn't really do linked lists. (I'm quite familiar with
what java does offer in terms of java.util.LinkList, but I don't really
count that as it is entirely missing any sort of node abstraction.) Of
course that doesn't preclude offering iterators, however iterators will
never be able to fully express what the underlying data structure is
attempting to represent. That said I've no objection to making the iterator
available as a convenience, although I'd probably call it getWorkIterator
rather than getWorkSequence.

> Right now my implementation is forced to cast to ConnectionImpl what
> breaks the purpose of the interface. Can you guys move it?

I'm happy to accept a patch for it, although I'd encourage you to check out
the events stuff in any case.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message