Hi Leigh, On Wed, Sep 19, 2012 at 3:10 PM, Leigh <lei...@gmail.com> wrote: >>> I missed the encoding parameter. While it's still possible to add that >>> to a static-only class, that would be more cumbersome and less correct >>> than instantiation (since the encoding is state, technically). My >>> apologies. Carry on ;-) > > It's probably already been covered, but I don't like the fact that > it's a class at all. > > There's nothing wrong with an ini value to start with (defaulting to X > if it is unrecofnised), then ini_set() to change the value at runtime > if required, and finally implementing everything as normal functions > that accept an override encoding as an optional parameter for those > one-off cases.
First off, bear in mind that the class is a preferred implementation that does not preclude the implementation of similar functions. As a class it just eases usage for those who are OOP obsessed ;). I work on Zend Framework and we already pass around a similar object. Secondly, the problem with a php.ini option or a default function parameter value is that it ignores the prevailing best practice of always specifying a character encoding explicitly. htmlspecialchars() is a perfect example here. Many uses will not specify an explicit encoding so we find applications with UTF-8 or other encodings for their output performing escaping to ISO-8859 in PHP 5.3. Please, search Github for htmlspecialchars - I'm not exaggerating. Now search for the same thing in any large framework and you'll never see this because those either followed best practice or already attracted a security report about it. Explicitly requiring the parameter just follows recommended practice. Now, let's consider adding it to php.ini. This follows the exact same reasoning as programmers will develop to their platform in ignorance of any others. It's just another assumed default that needs to be tweaked anyway - and probably will be only rarely. The point here is to eliminate opportunities to do this wrong and simplify doing it correctly. Flexibility for flexibility's sake doesn't actually solve an existing poor practice - it simply gives it a new life extension. Programmers need to know that character encoding selection is intrinsic to escaping. How many programmers will be stranded by PHP's switch to UTF-8 because they actually did use ISO-8859 output encoding? How many are stranded with UTF-8 escaping from PHP 5.4 while not using that encoding? Being explicit may be perceived as a PITA per function call but its necessary to eliminate unpredictability in the backend. > It feels like this is just using classes for the sake of using > classes, adding an unnecessary layer of complexity (and discussion) > for no real reason except that is the RFC authors preference. Anything any class can do, could be done procedurally. That doesn't mean it is. Many programmers use objects, dependency injection and all that other stuff. Adding the class simplifies usage in an OOP setting and ideally helps remove the barrier of having to rewrap functions into a class for those who do practice OOP regularly. So, yes, obviously it's a preference but not an unnecessary layer of complexity since it actually simplifies overall usage in the OO setting. Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
