> > I'm just trying to help explore your idea, not trying to shoot it down.
I never felt like you tried to shoot it down :-) > In general, though, if you can solve a problem satisfactorily without > writing > any new code, that's better, isn't it? Indeed. > > > Yes, if multiple deprecation error types is a requirement, and cannot be > satisfied simply with E_USER_NOTICE and establishing a convention for the > deprecation notice message text, then perhaps a custom solution is needed. > However, it's not clear that this is so important that it justifies a new > component. How many things are expected to become deprecated in ZF 2.0? > Will the messages be so numerous to require special classes to report them? Now that I come to think of it, probably no. > > > You could also consider using Zend_Log for deprecation messages. Create a > Zend_Log object and store it in the Zend_Registry under a documented key, > such as 'Zend_Deprecation_Log'. Each class or method that needs to report > deprecation would check the registry to see if that key exists and contains > a Zend_Log object. If so, use it. If no such object exists, then be > silent. Zend_Log allows the developer to customize logging output, > including filtering levels. Also you can create custom logging levels for > one or more deprecation levels. Good idea! You'd want a static method to do the above, so why not add it to Zend_Debug, > which many folks have complained is a bit thin anyway. Sounds reasonable. Thanks for your input! I'm glad my announcement did at least start a discussion about a reasonable way of showing the developer what is deprecated. Your Zend_Log suggestion is the better idea! Best regards, Tobias
