Sounds fine to me. +1
On 9/21/07, Albert Strasheim <[EMAIL PROTECTED]> wrote: > > Hello > > Maybe MessageListener::onMessage should be fixed to pass a non-const > Message > instead of pretending that BytesMessage::read is const when it isn't (also > consider something like std::istream::read, which isn't const). > > In my experience mutable is typically used when you have a getter that is > const but updates some kind of internal cache in the object. I think the > BytesMessage::read situation is more like std::istream::read than it is > like > this case. > > Cheers, > > Albert > > ----- Original Message ----- > From: "Motl" <[EMAIL PROTECTED]> > To: <users@activemq.apache.org> > Sent: Friday, September 21, 2007 1:45 PM > Subject: Re: BytesMessage constness > > > > Done. > > > > https://issues.apache.org/activemq/browse/AMQCPP-143 > > > > > > nmittler wrote: > >> > >> I agree, this definitely would be a pain since the onMessage method > gives > >> you a const Message. Could you capture this issue in JIRA? > >> http://issues.apache.org/activemq/browse/AMQCPP > >> > >> Thanks, > >> Nate > >> > >> > >> On 9/21/07, Motl <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>> Hi, > >>> I once asked you why readBytes() and other read methods aren't const: > >>> > >>> > http://www.nabble.com/BytesMessage-methods-tf3833767s2354.html#a10853672 > >>> > >>> But if only the stream pointer is updated, I suppose we could have > >>> another > >>> solution here, i.e. > >>> declare inputStream field as 'mutable': > >>> > >>> mutable io::ByteArrayInputStream inputStream; > >>> > >>> In that case we could keep read methods const. > >>> > >>> I am requesting for that because at the moment such non-const API > forces > >>> app > >>> level either always deal with non-const objects or make > >>> const_cast<cms::BytesMessage *>(), that's not good. > > >
