On Wed, Aug 31, 2011 at 11:27 AM, Peter Brinkmann < peter.brinkm...@googlemail.com> wrote:
> On Wed, Aug 31, 2011 at 9:01 AM, Dan Wilcox <danomat...@gmail.com> wrote: > >> >> On Aug 31, 2011, at 8:45 AM, Peter Brinkmann wrote: >> >> >> On Wed, Aug 31, 2011 at 6:25 AM, Dan Wilcox <danomat...@gmail.com> wrote: >> >>> I think it's much simpler to just add a call to get/set the message >>> limit, say: >>> >>> int libpd_max_message_length(); >>> void libpd_set_max_message_length(int length); >>> >>> This doesn't break any current code. >>> >>> Having to set a custom limit each time is far more tedious then just >>> setting it at startup. >>> >> >> 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's easy to fix. The language bindings for Java and Objective-C >> actually became simpler when I updated them for the new version. >> >> I don'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's the tiny extra effort of >> passing in the limit every time you start a message, or you don't have an >> a-priori limit, in which case you need to check the length before assembling >> a message anyway. >> >> Another aspect is API design. One feature of a good API is that it'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. >> >> >> ... 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't bother >> changing the limit and those that do will just pick a larger size with >> plenty of space anyway. It's too much work to bother setting it EACH and >> EVERY time. It'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 ... ? >> > > Actually, I don't mean to make people compute the size every time The > length parameter in libpd_start_message merely makes sure that you'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. > By the way, there's also a third way between specifying the max size every time and creating a convenience function. The start message function will only allocate new memory if the requested size is larger than what was requested before. You can also say libpd_start_message(MAX_SIZE) right after you initialize libpd, and then start all messages with libpd_start_message(0), where 0 means that it'll just use whatever was allocated before. This is convenient, but it doesn't quite look right to me, so I'd probably still go with convenience functions. Peter
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list