On Wed, Sep 19, 2012 at 10:48 PM, Michael Shadle <mike...@gmail.com> wrote: > On Tue, Sep 18, 2012 at 10:32 AM, Pádraic Brady <padraic.br...@gmail.com> > wrote: >> Hi Michael, >> >> See the link near the bottom of the RFC - even htmlspecialchars() has >> unusual behaviour that's potentially insecure. I have no objections to >> there being functions, of course, and the RFC makes that clear. >> However, many programmers like me are obsessed are objects so having >> an SPL class will obviously be near and dear to my design patterned >> heart ;). > > After looking over the RFC finally, would it be that crazy to consider > this an extension of the standard string functions? > > str_escape($string, $encoding, $flags) or probably better > str_escape($string, $flags, $encoding) - since encoding could be
I'm also proposing escape_var(), just like filter_var(). If it's str_escape() then that's still sane, it's consistent and that's all that matters. :-) - Paul. > defaulted to UTF-8, but flags are really what differentiate the > behavior... > > Then there is not a handful of functions but rather one that can be > used as the abstraction point and the flags passed to it will change > it's behavior, much like the filter functions. > > (I just see this falling under one solid defacto escape function > standard, and it could live by itself as "escape" or something, or as > it operates on strings, prefix it as such) > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
