[zeromq-dev] (no subject)

[Matt Weinstein]

On Apr 22, 2011, at 2:05 AM, Pieter Hintjens wrote:

> On Fri, Apr 22, 2011 at 7:27 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> 
>> Ok. Another problem: Copy of a const message should be a const message.
>> Imagine this prototype:
>> 
>> int zmq_msg_const_copy (const zmq_msg_t *dest, const zmq_msg_t *src);
>> 
>> The message passed as 'dest' is closed (non-const operation), then
>> filled-in by the copy of the const message. Yet the parameter cannot be
>> both const and non-const at the same time.
> 
This may be stretching the semantics a bit, but you could use the iterator model, and have two zmq_msg types:

	const_zmq_msg_t
	zmq_msg_t

Then the intended semantics w/could be preserved (as well as the transforms).

Unfortunately, the name mangling may start getting out of control at this point :-)

> Isn't the problem here that you're mixing two methods in one, i.e.
> 'delete and then copy into'?
> 
> The side-effect of deleting any previous message is not nice,
> especially since the rest of the message API is so pedantic.
> 
> If you made the copy semantics clean, the copy would be a const message.
> 
> I also like the idea of renaming 'close' to something more sensible,
> delete (confusing IMO) or destroy (better).
> 

Perhaps "release" might be better, since destroy / delete imply immediacy, whereas release usually means GC (someday)....?

> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev