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. /Per Jessen, Zürich -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
