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

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 >>