On 26-07-2013 15:59, Johannes Schlüter wrote:
Such a way for overloading is bad. This is painful on each update. If there are different things to do use different hooks. The implementations might call the same implementation but a "purpose" option leads to a long term maintenance hell whenever there is a change.(a tiny bit better would be using an enum instead of int as in some situations compilers/analyzers might give a hint ... but still a mess)
This is a gross misrepresentation. The vast majority of extensions will not care about this purpose, just like most extensions do not care about get_debug_info or get_gc or about the purpose in read_property. If a new purpose is added, this would not be any different than adding a new hook as long as:
1) the extension doesn't purposefully break forward compatibility, for example by doing switch(purpose) { ... default: panic(); } and 2) the new hook would default to get_properties, either by explicitly setting the pointer to get_properties in the standard handlers array or by having the engine fall back to get_properties (the last one was the solution adopted for get_debug_info and get_gc afaik).
Yes, this would break extensions. But we never made any promises about source BC for extensions. In fact, we actually break it for every release, sometimes in rather subtle ways like in 5.4 (due to interned strings, and object properties storage).
So what is being proposed is to extend our already too large API with yet another way of doing something for edge cases for which we have a good solution for the general case already.
Alternatively, could the problem perhaps be mitigated by making available some utility functions for serializing native types?
-- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
