Stas, On Tue, Sep 18, 2012 at 2:21 PM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi! > > > Filter has already gone down this road--I doubt the value added by > having a second, much > > more verbose way to call htmlspecialchars()--but I don't see why we must > continue down > > that path. > > So, you don't think there should be second, more verbose way to call > htmlspecialchars - that's why we should add third, more verbose way to > call htmlspecialchars? Somehow this does not sound convincing to me. No, we shouldn't. We should stick with oddly named functions with dubiously complicated parameter combinations that nobody gets right, because they are already there, and that's good enough, right? </sarcasm> Look. Just because it's possible, doesn't mean that it shouldn't be improved. The filter API is great. It really is. But for escaping output, it's basically useless because it's not designed for that. It's designed for filtering data. You can use it for "sanitizing", but that's more of a hack. For example, filter will only work on the default character set ( http://www.php.net/manual/en/ini.core.php#ini.default-charset). But I may have other character sets that I talk to different systems on. And Filter has no way of handling that. Filtering is a global concern. Escaping is a context concern. There's a huge difference. You can keep cramming the escaping concerns into a global filter handler all you want. Or we could stop, and think about designing proper APIs for a change. Where the API imparts both implementation and semantic meaning. An API where it's easy to see if a user gets it right or not. Personally, I'd rather have a dedicated API. It's the only way that semantic meaning of the API will be preserved. In this case, I would start it as a PECL extension implementing the ESAPI library. Get the API right, and prove it works, then pull it into core.
