Re: Re: RFC: Implementing a core anti-XSS escaping class
| From: | Leigh | Date: | Wed, 19 Sep 2012 14:10:20 +0000 |
| Subject: | Re: Re: RFC: Implementing a core anti-XSS escaping class | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-63137@lists.php.net to get a copy of this message | ||
>> 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.
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.