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 ... ? In case, my wrapper will include max message size get/set functions and complain to cout when something is out of bounds. > Cheers, > Peter > > > > On Aug 30, 2011, at 5:47 PM, Peter Brinkmann wrote: > >> >> >> On Tue, Aug 30, 2011 at 3:44 PM, Mathieu Bouchard <ma...@artengine.ca> wrote: >> On Tue, 30 Aug 2011, Peter Brinkmann wrote: >> >> For the time being, I have something much simpler in mind: Just take the >> current call "int libpd_start_message(void)", which returns the current >> limit, and replace it with "int libpd_start_message(int length)", which >> takes a parameter indicating the length of the message and returns a nonzero >> error code if the length is too big. >> >> But this means that new libpd-using apps won't compile with old versions of >> libpd AND vice-versa. >> >> Well, the vast majority of users won't notice any difference at all because >> they're using the Android or iOS branch, which I'm updating as I go along. >> The only people who are affected by this are those who are using the C >> library directly, and I hope that they'll either be willing to update their >> code (which should be no more than a two-line change in most cases) or just >> stick to the current version, which will remain available via git. >> >> In any case, I think everybody understands that this is still a young >> library that needs to adapt as we gain a better understanding of how people >> are using it, and the cost of making a small incompatible change is a lot >> lower than choosing a suboptimal solution for compatibility with an earlier >> version. This period of youthful innocence is coming to an end, though; the >> API has been quite stable for quite a while now, and I believe that it'll >> soon be time to declare it finished. I want to take a critical look at >> every piece before we officially lock the API, and I won't be afraid to cut >> things that may turn out to be a burden in the long run. (That's why I >> floated the idea of getting rid of the simple message assembly mechanism, >> but it looks like that's here to stay.) >> Cheers, >> Peter >> > > -------- > Dan Wilcox > danomatika.com > robotcowboy.com > > > > > -------- Dan Wilcox danomatika.com robotcowboy.com
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list