On 19/09/12 17:06, Michael Shadle wrote:
It feels like this is just using classes for the sake of using
classes, adding an unnecessary layer of complexity (and discussion)
for no real reason except that is the RFC authors preference.
+1
First the discussion was filtering vs escaping. Now it is about how to
implement it as a class etc.
I don't understand why people have any issue with it being a core procedural
function. You can call that from your OO code just fine. Just like any other
core procedural function.
Yes, but typing the encoding every time is cumbersome. Or, if you don't
want to set it every time, you'd have to set it globally. Then, you
forgot to change it back somewhere when you're dealing with multiple
encodings, and it all goes wrong.
There is no reason it has to be OO. OO has to call procedural functions already
(string functions, array functions, curl, json, etc etc); but us procedural
purists don't have to call OO methods and classes if we don't need to (except
now some of the DateTime IIRC which bugs me :p)
Anyway how hard is it to use something akin to the filter functions? That's
what constants/flags are for.
Call it str_escape(string, flags optional, encoding optional) and be done with
it. Since it won't be useful to have escape_var or escape_input type of
differentiation and this seems like it could just fit under the string family
of functions (I am a fan of namespaced functions by prefix)
After that it seems like the discussion would be:
1) do we even need encoding or is UTF8 just fine
UTF8-only is certainly not just fine.
2) what are the flags to be defined for different escaping methods
$.02
--
Andrew Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
