Tobias Gies wrote:
>
> I'm all for simplicity, I just thought it could be useful to have multiple
> deprecation error types. If others agree that simply throwing an
> E_USER_NOTICE error is enough, we may well archive the proposal.
>
I'm just trying to help explore your idea, not trying 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?
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?
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.
So you'd leverage an existing part of ZF. Unless of course Zend_Log becomes
deprecated! ;-)
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.
Regards,
Bill Karwin
--
View this message in context:
http://www.nabble.com/Zend_Deprecation-is-ready-for-community-review.-tp18513175p18517017.html
Sent from the Zend Framework mailing list archive at Nabble.com.
