Hi!
Still, that API is likely wrong: a library function written by someone completely unrelated to the main application shouldn't be echoing anything through the output. And if it's not generating the html, the htmlspecialchars is better done from the return at the calling application (probably after converting the internal charset).
Again, you making a huge amount of assumptions about how ALL the applications must work, which means you are wrong in 99.(9)% of cases, because there's infinitely many applications which don't work exactly like yours does, and we have no idea how they work.
The main point is that having global state (and yet worse, changeable global state) significantly influence how basic functions are working is dangerous. It's like keeping everything in globals and instead of passing parameters between functions just change some globals and expect functions to pick it up.
Such interfaces may be well served by switching the setting many times.
That's exactly what I am trying to avoid, and you are just illustrating why this proposal is dangerous - because that's exactly what is going to happen in the code, instead of passing proper arguments to htmlspecialchars people will start changing INI settings left and right, and then nobody would know what htmlspecialchars() call actually does without tracking all the INI changes along the way.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
