Riggs, Rob wrote:
-----Original Message-----
From: Gordon Sim [mailto:[email protected]]
Sent: Thursday, September 10, 2009 11:06 AM
To: [email protected]
Subject: Re: [c++] latest messaging api patch
On 09/10/2009 05:35 PM, Alan Conway wrote:
Given a choice between:
message.getSession().reject(message)
message.reject()
the latter seems simpler, more intuitive and less error prone. Why
complicate the API because of the way the implementation works?
My personal preference is still for Session::reject(const Message&),
with the requirement that the message has been received on that session
(and not previously acknowledged) made very clear in the documentation.
Alan's suggestion is my preference. APIs should be designed to be difficult,
if not impossible, to use incorrectly. The conciseness of Alan's suggested API
is also a virtue.
Otherwise, what would be the behavior if the wrong session is asked to reject
the message? And what overhead does that entail?
I agree with the principle, but this assumes that it's possible for the
implementation to always maintain a pointer from the message to the
session that you actually want to use, otherwise message.reject() may
end up doing something that you didn't necessarily intend.
With session.reject(message-id) you are always going to get exactly what
you ask for or a clear exception that the id is unrecognized. So I'd
argue that the principle may actually suggest this form rather than
message.reject().
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
