Re: Decorators Revisited

On Tue, Aug 14, 2012 at 8:36 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote: > Hi! > > > 2. Move instanceof to a handler from the current standalone function. > Then > > each (pecl level) class could choose its own implementation if it is > > needed. The function could still exist for BC reasons, but would proxy to > > the handler method if it existed... Then, the wrapped class (the > additional > > pointer) would only need to live on the objects internal store... > > I don't think overriding instanceof is a very good idea. instanceof has > very defined meaning, which implies certain contract between classes and > their clients, and allowing everybody to override it to mean whatever > one likes looks very dangerous to me. > I think you are excagerating, the proposal is not allowing everybody to overwrite instanceof it to do whatever. That would be if we could overwrite the implementation of instanceof in userland. Instead it simplifies applying the decorator pattern on the language level, and the instanceof only in this use-case. @Anthony: Does this handle get_class() as well and all the Reflection APIs?