On 13/03/12 00:25, Stas Malyshev wrote: > 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. No. I'm saying how I consider they should work, saying that an API doing otherwise is likely* wrong (aka. has a bad design), very much as I'd consider insane a company policy stating "PHP function arguments shall be named $a, $b, $c...". That's obviously my opinion, but I think most applications will conform to that, just as most apps will use more descriptive argument names than "$c"**.
* There might be some very very special application where it turns out to be an appropiate design, but that would be the exception. ** Even though there are 26!/(26-n)! ways to name so badly the arguments of a n-ary function. > 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. I agree with you, in the general case. Yet, I consider the html charset to be a global state. And passing the global variables as parameters on each function call would be nearly as bad as passing parameters as globals. I just positioned the opposite way for parse_str(), while being fully aware of that. >> 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. That's assuming people would need to use different output charsets, which I don't consider to be the case. How many people is using now the third htmlspecialchars() parameter? What makes you think that they would need to change the default global, *several times per request*? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
