Hi Rowan, On Thu, Mar 5, 2015 at 10:16 AM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> On 4 March 2015 21:27:53 GMT, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > >We cannot remove all issue at once. We are better to adopt incremental > >improvement, aren't we? > > I think this, more than anything else, is where I disagree (having been > persuaded by arguments in previous discussions). Incremental improvements > mean having the cost of change multiple times, and the benefit just a > promise for the future. It's like living in a building site while > rebuilding your house - sometimes necessary, but not what you'd choose. > > If we have two names with no other fixes now, then later a third name, or > some magic flag, which fixes the argument order and error behaviour, then > go through and tidy up, we'll end up with a whole flow chart of "if you > need to support version X, use Y; if you find a tutorial using A, replace > with B..." > > Some such change is inevitable - a huge number of tutorials became out of > date when ext/mysql was deprecated, for instance - but it's not something > to do "little and often" just to make things "a little bit better". Sounds reasonable. I've updated RFC to note not addressed inconsistencies explicitly. There may be others. Some of these may be addressed by this RFC. https://wiki.php.net/rfc/consistent_function_names#unaffected_php_functionality ----------------- Unaffected PHP Functionality This RFC only addresses inconsistent names. These are the list of related inconsistencies. - Parameter order inconsistency. This may be addressed by “default namespace” in other RFC. - Return type inconsistency. Most severe inconsistency is “wrong number of parameters returns NULL”. This may be addressed by “INI switch” in other RFC. - Constant name inconsistency. - Class and method names. Only “__set_state()” and “create_sid()” methods are addressed. Future Scope - Use of namespace to clean up global namespace at all. - New APIs that replace old APIs. - Parameter order inconsistency. - Return type inconsistency. - Constant name inconsistency. - Class inconsistency. ---------------- Functions return NULL for wrong number of parameters is easy one to fix without BC. We may have INI switch return FALSE for invalid number of parameters. return_value_consistency=On/Off ; Returns FALSE when number of parameter is wrong for module functions. Parameter ordering issue may be addressed also. Instead of having alias, we may introduce new functions for them. The new function name could be issue, though. If you know good list of functions have strange parameter ordering, I appreciate it. Parameter ordering issue could be addressed by "default namespace" that can import functions/classes to root namespace. This approach requires more work, but it would be cleaner than simply having new API. I think this issue would be large enough to be a RFC, though... Do you have particular suggestions? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
