On Tue, 2007-12-11 at 22:11 +0100, Per Jessen wrote: > Robert Cummings wrote: > > > On Tue, 2007-12-11 at 18:14 +0100, Per Jessen wrote: > >> I have been trying hard not to join this thread, but ... apart from > >> the principle, what's _really_ so poor about it? Having to write > >> application code that needs to work with two different APIs is poor > >> enough, using a session variable for keeping a status won't make it > >> much worse. So what if the status is server-scope, yet kept in > >> user-scope. In particular if the app already uses session storage. > > > > It's bad because it places data in a storage area not related to the > > kind of configuration being tracked. Sessions are for managing user > > and user related data. This particular value is related to the server > > in general. It places a large WTF factor on the code for anyone down > > the road maintaining it. > > Possibly, but nothing that a single line comment won't explain. Making > a potentially poor decision is bad, but explaining why takes most of > the sting out of it. > > > It may be true that nobody else will ever > > manage this code, but it's unlikely. I absolutely agree with you > > though, the whole design is off. The best way to do this IMHO is to > > use a singleton class that only loads the appropriate library type. > > I can't remember what sort of environment the OP was in, but if any sort > of organised testing is done, the use of two different APIs will just > about double the test-effort. Which is why I still think the best > option is to mandate _one_ of the APIs and choose your hoster > accordingly. Well if you write unit tests, having the unit tests applied to one or the other is the same amount of work since it just requires a switch to change between mysql and mysqli. Cheers, Rob. -- ........................................................... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ........................................................... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
