On Wed, Aug 31, 2011 at 9:01 AM, Dan Wilcox <span dir="ltr">&lt;<a href="mailto:danomatika@gmail.com">danomatika@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;"><br><div><div class="im"><div>On Aug 31, 2011, at 8:45 AM, Peter Brinkmann wrote:</div><br><blockquote type="cite"><br>On Wed, Aug 31, 2011 at 6:25 AM, Dan Wilcox <span dir="ltr">&lt;<a href="mailto:danomatika@gmail.com" target="_blank">danomatika@gmail.com</a>&gt;</span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div style="word-wrap: break-word;">I think it&#39;s much simpler to just add a call to get/set the message limit, say:<div><br></div><div>int libpd_max_message_length();</div><div>void libpd_set_max_message_length(int length);</div>

<div><br></div><div>This doesn&#39;t break any current code.</div><div><br></div><div>Having to set a custom limit each time is far more tedious then just setting it at startup.</div></div></blockquote><div><br>Actually, breakage of current code is a feature as far as I am concerned because it makes people aware of the change, and it should be harmless because it&#39;s easy to fix.  The language bindings for Java and Objective-C actually became simpler when I updated them for the new version.<br>

<br>I don&#39;t think the new signature of libpd_start_message is tedious, really.  Essentially, I see two use cases: Either you know an a-priori limit on your message length, in which case there&#39;s the tiny extra effort of passing in the limit every time you start a message, or you don&#39;t have an a-priori limit, in which case you need to check the length before assembling a message anyway.<br>

<br>Another aspect is API design.  One feature of a good API is that it&#39;s difficult to use incorrectly.  With a separate call for setting the message limit, people will forget that the limit is a consideration.  With the current solution, people will briefly contemplate the length of each message they start, which is a good thing.<br>
</div></div></blockquote><div><br></div></div><div>... but you can simply return an error or print a message complaining when the message is too long. My whole point is that most people won&#39;t bother changing the limit and those that do will just pick a larger size with plenty of space anyway. It&#39;s too much work to bother setting it EACH and EVERY time. It&#39;s far LESS elegant, and dare I say intuitive. It seems like an unnecessary step. [eople that have problems will only run into this once, increase the max size, and then be fine. Why force them to compute a size manually each time when they could just be happily adding objects ... ?</div>
</div></div></blockquote><div><br>Actually, I don&#39;t mean to make people compute the size every time  The length parameter in libpd_start_message merely makes sure that you&#39;ll have enough space for that many elements; the number of elements in the actual message may be smaller.  If you know that your messages will never exceed a certain length, then you can simply use that maximum length every time.  In that situation, I would just wrap the call to libpd_start_message in a macro or a convenience function to get exactly the effect that you want.<br>
<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;"><div><div><br></div><div>In case, my wrapper will include max message size get/set functions and complain to cout when something is out of bounds.</div>
</div></div></blockquote><div><br>And with the streaming API that you&#39;ve built in C++, that&#39;s the right thing to do:)<br>Cheers,<br>      Peter<br><br></div></div>