On Sat, Sep 7, 2013 at 10:36 AM, Nikita Nefedov <inefe...@gmail.com> wrote:
> On Sat, 07 Sep 2013 20:08:45 +0400, Michael John Burgess < > mich...@mjburgess.co.uk> wrote: > > On 07/09/2013 15:41, Levi Morrison wrote: >> >>> It looks nicer than Escaper::escapeJs(), Escaper::escapeHtml(), etc. >>>> >>>> Any comments? >>>> >>> >>> >>> Please, don't go down this route. You do not want one class to escape all >>> kinds of data; delegate each type of escaping to its own class: >>> >>> JavaScriptEscaper->escape(); >>> PhpEscaper->escape(); >>> HtmlEscaper->escape(); >>> HtmlAttributeEscaper->escape()**; >>> >>> I should not have to defend this but I am willing to explain in more >>> detail >>> if someone would like me to. >>> >>> >> >> There doesnt need to be any object-oriented version for this problem. >> It's a series of pure functions. Wraping them in one or more classes adds >> nothing. >> >> Michael >> >> > Hi, > > Wrapping those functions in methods means they can be extended in child > classes. So suppose you have some library that takes object of type > Spl_Escaper and uses its methods for escaping some data. Now if you will > need some additional escaping you just need to make child class for > Spl_Escaper and override methods which behavior you need to change. This > can't be done with pure functions (in PHP). You have a flawed understanding of good functional design. Instead of directly calling the escaping function you would simply ask for a callable and pass in the escaping function. Thus, you could use an alternative escaping function at runtime. The methods route is a poor choice. If we use classes at all, separate the responsibility of each type of escaping to a separate class. Escaping JSON and HTML code have little (possibly nothing) in common and do not belong in the same class.
