# [RFC] Escaping RFC for PHP Core - Updates?

- Thread: https://externals.io/message/68934
- Original archive: https://news-web.php.net/php.internals/68934
- Started by Yasuo Ohgaki on 2013-09-07T03:36:26+00:00
- Messages: 13
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #68934 — Yasuo Ohgaki — 2013-09-07T03:36:26+00:00

URL: https://externals.io/message/68934#68934

Hi,

Any updates for  "Escaping RFC for PHP Core"?
https://wiki.php.net/rfc/escaper

I think this is must have item for next PHP.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #68936 — Leigh — 2013-09-07T05:56:43+00:00

URL: https://externals.io/message/68934#68936 · In reply to: #68934

>
> Hi,
>
> Any updates for  "Escaping RFC for PHP Core"?
> https://wiki.php.net/rfc/escaper
>
> I think this is must have item for next PHP.
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net

Looks like the rfc author was unable to implement it himself at the time of
the proposal.

The last thing in the discussion thread looks like "implement it in PECL
first, and it might get bundled later"

http://marc.info/?l=php-internals&m=134822086426610&w=2

---

## #68939 — Yasuo Ohgaki — 2013-09-07T08:35:07+00:00

URL: https://externals.io/message/68934#68939 · In reply to: #68936

Hi Leigh,



> Looks like the rfc author was unable to implement it himself at the time
> of the proposal.
>
> The last thing in the discussion thread looks like "implement it in PECL
> first, and it might get bundled later"
>
> http://marc.info/?l=php-internals&m=134822086426610&w=2
>
Thank you for the info. I searched my mailbox, but I couldn't find this.

It would be better to implement this as SPL_Escape class.

SPL_Escape::jsString()
SPL_Escape::phpString()
SPL_Escape::html()
SPL_Escape::htmlAttribute()
etc

It looks nicer than Escaper::escapeJs(), Escaper::escapeHtml(), etc.

Any comments?
Anyone mind if I edit the RFC?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #68940 — Pierre Joye — 2013-09-07T08:51:03+00:00

URL: https://externals.io/message/68934#68940 · In reply to: #68939

Hi,

>
> Hi Leigh,
>
> 
>
> > […]
> Thank you for the info. I searched my mailbox, but I couldn't find this.
>
> It would be better to implement this as SPL_Escape class.
>
> SPL_Escape::jsString()
> SPL_Escape::phpString()
> SPL_Escape::html()
> SPL_Escape::htmlAttribute()
> etc
>
> It looks nicer than Escaper::escapeJs(), Escaper::escapeHtml(), etc.
>
> Any comments?
> Anyone mind if I edit the RFC?

I like the goal of this proposal.

It would however fits much better in ext/filter. Yes, escaping has
different purposes than filtering.

I have some worries about the implementation. It is not an easy task and
some external libraries may already have these features (esp. CSS or JS).

About the API:

To have a kind of wrapper class is not very useful. It will most likely end
with static methods with a large set of arguments or options array, not
very sexy.

Cheers,
Pierre

---

## #68942 — Levi Morrison — 2013-09-07T14:41:38+00:00

URL: https://externals.io/message/68934#68942 · In reply to: #68939

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

---

## #68945 — Michael John Burgess — 2013-09-07T16:08:45+00:00

URL: https://externals.io/message/68934#68945 · In reply to: #68942

> > […]
>
>
> 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

---

## #68946 — Nikita Nefedov — 2013-09-07T16:36:30+00:00

URL: https://externals.io/message/68934#68946 · In reply to: #68945

On Sat, 07 Sep 2013 20:08:45 +0400, Michael John Burgess  
<michael@mjburgess.co.uk> wrote:

> 
> > […]
>
>
> 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).

---

## #68947 — Levi Morrison — 2013-09-07T16:36:47+00:00

URL: https://externals.io/message/68934#68947 · In reply to: #68945

On Sat, Sep 7, 2013 at 10:08 AM, Michael John Burgess <
michael@mjburgess.co.uk> wrote:

> 
>
> > […]
>
> 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.


If you are making a class then do it properly; if you aren't using a class
then use sensible functions. Using a poorly designed class as originally
proposed is not helping anything and may hurt as well.

---

## #68948 — Levi Morrison — 2013-09-07T16:43:01+00:00

URL: https://externals.io/message/68934#68948 · In reply to: #68946

> On Sat, 07 Sep 2013 20:08:45 +0400, Michael John Burgess <
> michael@mjburgess.co.uk> wrote:
>
>  
> > […]
> 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.

---

## #68951 — Florin Patan — 2013-09-07T16:55:25+00:00

URL: https://externals.io/message/68934#68951 · In reply to: #68948

> 
>
> > […]
>
>
> 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.


How about allowing to register a custom escape function for each type
which can override the native one or the previous registered one?
There should be no way to restore a previous user registered function
but there should be a way to reset it to the internal php one. That
would solve the described problem as well as keeping it simple.
And having this as a class doesn't add anything imho, mainly due to
the point described above by Levi.


Kind regards
----
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

---

## #69368 — Yasuo Ohgaki — 2013-09-27T00:52:31+00:00

URL: https://externals.io/message/68934#69368 · In reply to: #68940

Hi Pierre,



> I like the goal of this proposal.
>
> It would however fits much better in ext/filter. Yes, escaping has
> different purposes than filtering.
>
> I have some worries about the implementation. It is not an easy task and
> some external libraries may already have these features (esp. CSS or JS).
>
> About the API:
>
> To have a kind of wrapper class is not very useful. It will most likely
> end with static methods with a large set of arguments or options array, not
> very sexy.
>

I agree. It would end up with static methods and not cool.
If it's going to be static method only calls, usual functions
are better.

ext/filter is a good option.
I'll add this in the RFC as a choice.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #69369 — Yasuo Ohgaki — 2013-09-27T00:53:34+00:00

URL: https://externals.io/message/68934#69369 · In reply to: #68946

Hi,



> On Sat, 07 Sep 2013 20:08:45 +0400, Michael John Burgess <
> michael@mjburgess.co.uk> wrote:
>
>  
> > […]
> 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).
>
>
I'm in favor of  implementing this in ext/filter now, but
extend-ability is good benefit.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

---

## #69370 — Yasuo Ohgaki — 2013-09-27T00:59:19+00:00

URL: https://externals.io/message/68934#69370 · In reply to: #68948

Hi,

On Sun, Sep 8, 2013 at 1:43 AM, Levi Morrison <morrison.levi@gmail.com>wrote:

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

You are proposing something like

$escape_function = function($input) {
    $output=avaScriptEscaper->escape($input);
     $output=do_some_additional($output);
     return $output;
}

my_escape($some_data, $escape_function) {
    return $escape_function($some_data);
}

Is this correct?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net