Re: Re: RFC: Implementing a core anti-XSS escaping class

From: 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.

« previous php.internals (#63137) next »