Hi! > This is exactly the issue we are battling here. One side wants to be > consistent with inconsistencies (and tbh quite confusing) while the other > side wants to allow userland implemented APIs to actually be consistent.
It's not the issue here. Nobody wants 100% of functions to do the same, and everybody knows there will be exceptions when some functions can not accept all values covered by type, or can accept multiple types but only in certain situations, etc. etc. What we want is to have one set of rules (yes, again, not covering 100% of functions, both user and internal, but covering most of them in the same way) instead of two different sets of rules. > I am not judging any of these sides but we are heading to a status quo > here, for no good reason. We all know that this is a feature desired by a > very large of our users. Let not block it. Nobody is "blocking it". What we're talking about is not making inconsistent arbitrary implementation that prevents us from making a consistent one (since if we introduce two inconsistent sets of rules, we won't be able to make it one consistent set of rules until the next major at least). In my opinion, it is better not to have it until it's ready than have it in a broken way just because "users want it" so we have no time to do it right. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
