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. > > 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 > Oh and just to throw that in: If the additional variable (or the extra line) is a "problem" echo (new Escaper)->escapeHtml('<b>test</b>'); // vs. echo Escaper::escapeHtml('<b>test</b>'); -- github.com/KingCrunch