Hi Michael, >> 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. > > +1 > > First the discussion was filtering vs escaping. Now it is about how to > implement it as a class etc. > > I don't understand why people have any issue with it being a core procedural > function. You can call that from your OO code just fine. Just like any other > core procedural function.
I have never once expressed a problem with this being a set of procedural function. Not once. The RFC offers some suggested function signatures. So nobody has expressed any issues and nobody has insisted that you be required to use a class or object. > There is no reason it has to be OO. OO has to call procedural functions > already (string functions, array functions, curl, json, etc etc); but us > procedural purists don't have to call OO methods and classes if we don't need > to (except now some of the DateTime IIRC which bugs me :p) Then please - call the functions as defined in the RFC. > Anyway how hard is it to use something akin to the filter functions? That's > what constants/flags are for. The RFC addresses escaping, not input filtering. Yes, there is a fine line between them but the filter method requires constants, options, and we would then need to later in character encoding. The resulting mutation would be a step backwards in my opinion in guiding users towards the secure use of escaping in applications. > Call it str_escape(string, flags optional, encoding optional) and be done > with it. Since it won't be useful to have escape_var or escape_input type of > differentiation and this seems like it could just fit under the string family > of functions (I am a fan of namespaced functions by prefix) > > After that it seems like the discussion would be: > 1) do we even need encoding or is UTF8 just fine > 2) what are the flags to be defined for different escaping methods Correct encoding is essential. The entire planet does not use UTF-8, and UTF-8 is not the same as other encodings once you get over the theoretical perfection that should exist and meet the rebels: browsers. Please bear in mind that using the correct encoding has been preached for many many years as a minimum requirement in secure escaping for PHP. 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
