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

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 On 19 Sep 2012, at 08:39, Tomas Creemers <tomas.creemers@gmail.com> wrote: > On Wed, Sep 19, 2012 at 8:34 AM, Sebastian Krebs <krebs.seb@gmail.com> wrote: >> >> >> 2012/9/19 Tomas Creemers <tomas.creemers@gmail.com> >>> >>> Hi all, >>> >>> >>> >>> If this is going to be implemented as a class, what is the advantage >>> of instantiation for this? Unless I'm missing it, I would propose that >>> the functions are made static. >>> > [snip] >>> >>> Regards, >>> >>> Tomas >> >> >> Hi, >> >> I guess the reason is the same like the one, why you just should avoid >> static methods at all. But only one example: Try to extend the class and >> then _always_ use the extended one ;) >> >> Regards, >> Sebastian > > > Isn't that what late static binding is for? It enables the use of the > extending class (if any) from the base class. > > 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 >