On Sep 19, 2012, at 10:55 AM, Pádraic Brady <padraic.br...@gmail.com> wrote:
> 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. Sorry; it just felt like the conversation was getting so heavy on syntax that people would be viewing the only way to implement the functionality would be requiring an OO interface to it. Look at all of the examples people post so far :) > 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. I brought up the filter functions as an example of semantics/syntax. Not functionality. I understand and agree with them being separate. > 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. As mentioned before I removed my discussion point about encoding. It was just an idea. I think it should be UTF8 by default but accept encoding as a parameter. I think we are probably on the same page here. I have not looked at the RFC but was just seeing floods of example code coming through the mailing list and started being vocal based on my concerns from that. An RFC doesn't mean it will happen exactly as the RFC defines it :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
