> 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. 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 2) what are the flags to be defined for different escaping methods $.02 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
