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

No need to apologise ;). Just wanted to clarify that the character encoding drives the choice of class since it can be easy to miss its importance - amended the RFC a little to highlight it. Paddy On Wed, Sep 19, 2012 at 12:55 PM, Tomas Creemers <tomas.creemers@gmail.com> wrote: > On Wed, Sep 19, 2012 at 9:58 AM, Pádraic Brady <padraic.brady@gmail.com> wrote: >> You did notice the character encoding parameter to the constructor? The point of the class >> is to share that little piece of state and omit it as a required method parameter thus removing one >> OOP layer for those practicing OOP like all the major frameworks. >> >> The RFC notes already that character encoding parameters are NOT optional. They MUST be set >> on each call outside of the class to enforce explicitness and prevent the currently popular option >> of imposing a non-configurable default in libs and frameworks. Character encoding is important in >> escaping and assuming that they are interchangeable doesn't always fit the reality of browser >> behaviour and bugs. >> >> This would apply to static calls as much as plain functions. >> >> Paddy > > 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 ;-) > > Tomas > > >> On 19 Sep 2012, at 08:39, Tomas Creemers <tomas.creemers@gmail.com> wrote: >> > [snip] >>> >>> I really don't see what class instantiation would add to this design >>> (if it's going to be a class at all). It doesn't have >>> instance-specific state. >>> >>> >>> Regards, >>> Tomas >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team