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

2012/9/19 Tomas Creemers <tomas.creemers@gmail.com> > 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. > late static binding is for runtime-resolvement of the class _within_ the class. If you spread the (external) call "FooEscaper::escapeJs()" all over you code, you'll have much fun changing every occurence of "FooEscaper" once you extend it. Regards, Sebastian > > 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 > -- github.com/KingCrunch