Rainer Gerhards writes: > I suggest to add a "_r" prefix, e.g. dbi_initialize() becomes > dbi_initialize_r(). I think this is in line with clib functions like > strerror() and strerror_r(). While the actual code fix with strerror() > (renentrancy) is not 100% identical to what we see here, I think it is > sufficiently close to justify the naming. But of course, this are just > my personal thoughts... >
Fair enough from my point of view. It's rather "recallable" than "reentrant", but this still makes an "_r"... > One thought on "deprecated" from my very limited point of view. I see > they are good to tell projects its time to upgrade. On the other hand, > there may be valid reasons to support both. For example, I intend to > check the version number and use dbi_initialize() if we are 0.8.3.1 or > lower - because that works well enough with my application in its > current state. And it is better to use what is there then to deny > functionality. After all, the user may be unable to compile a package > himself and so relies on whatever the distro provides - and that may be > an older release. Of course, I can issue a warning message in that case, > so that the more knowledgeable user can update. The bottom line is that > with that logic, the "deprecated" message will always spoil my build > log, which is a cosmetic issue but still not nice ;) > I see one of the main effects of "deprecated" messages to prevent the use of these functions in *new* code, which works best by violating the aesthetics of the developers :-) If package maintainers do their job, the "deprecated" messages will eventually go away also for those users that prefer packaged code - its all a matter of time. regards, Markus -- Markus Hoenicka [EMAIL PROTECTED] (Spam-protected email: replace the quadrupeds with "mhoenicka") http://www.mhoenicka.de ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ libdbi-users mailing list libdbi-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libdbi-users