> It would be better to return the previous handler, or NULL if one > wasn't set, in the same way as set_error_handler() does, and for the same reasons.
Well, maybe you are right. But I thought, this is not a use case, usually we don't need multiple handlers for certain context. I.e. we don't need to encode single quotes in HTML as ''' in one template and as ''' in another. Use case would be the following: if there is no handler for 'my_context', register this handler. If some library really need to replace existing handler of application, it can call unregisterHandler() directly. Also in Twig there is no such behavior, and applications with it work good. I tried not to invent new mechanisms of usage. > Also, shouldn't these just be functions? Why is there a class involved > when it only has static functions/state? I didn't want to add many related items to a global namespace. And with class we can use autoloading and fully replace an implementation, unlike functions. It is possible to disable extension and use own class.
