for order purposes looks like #3 is a good thing +1
--Victor Lucero Plugin developer wannabe. El 09-12-2010, a las 13:42, Jason escribió: > I have to admit that #3 would be very useful, and would help plug-in > developers. +1 for that. > > On Dec 9, 2010, at 11:14 AM, Igor Galić wrote: > >> >> ----- "Leif Hedstrom" <zw...@apache.org> wrote: >> >>> Hi all, >>> >>> there's been some discussions about cleaning up how our APIs (SDK) >>> deals >>> with return values. Right now, it's sort of a mess, with different >>> APIs >>> using different standards (e.g. return a POD data type, return a >>> TSReturnCode, return an int etc.). There are a few suggestions on the >>> >>> table, each which has pros and cons. I'd like to start the discussion >>> on >>> this, so we can come to a consensus and make any changes sooner rather >>> >>> than later. >>> >>> Here are the ideas that I've heard so far: >>> >>> 1) Do nothing (or as little as possible). >>> >>> 2) Do nothing, other than making sure any outright wrong returns are >>> fixed (i.e. use of "int" when it should be TSReturnCode). Things >>> return >>> POD values or pointers stays the same. See TS-271 for example. >>> >>> 3) Change all APIs to always return TSReturnCode. The prototype for >>> many >>> functions would then change, to be like >>> >>> TSReturnCode TSFooApi(type1 in_param1, type2 in _param2, type3 >>> *out_param1, type4 *outparam2); >>> >>> >>> >>> #3 is obviously the thing with the most work (and changes), and also >>> is >>> slightly more cumbersome to use in some cases (i.e. where before >>> something could return a char*, where NULL means failure, we'd now >>> pass >>> in a char** pointer, and return TSError on failure). Also, some APIs >>> that can never fail would always return TS_Success, which makes it >>> slightly more confusing to know when I need to check for a return >>> value >> >> I've been thinking about leaving those functions which don't have >> a return value to be void >> >> But that would eliminate the biggest + with this option. >> >>> or not (although, a plugin author can of course always check every >>> APIs return value). >>> >>> On the positive side of #3 is that the APIs become very standardized, >>> and easier to remember. And there is no guess work as to what return >>> value means success or failure, or checking for the wrong return >>> values. >>> >>> Thoughts? >> >> Complete Consistency. >> +1 >> >>> -- leif >>> >>> P.s >>> If we go with option #1 or #2, there are a few new APIs that should >>> most >>> likely change, since they currently use the #3 prototype. Not a big >>> deal, since there were added in the v2.1.x timeline, so there is no >>> compatibility that breaks. >> >> i >> >> -- >> Igor Galić >> >> Tel: +43 (0) 664 886 22 883 >> Mail: i.ga...@brainsware.org >> URL: http://brainsware.org/ >
