Hi! > 2. Throw a notice if a parameter name is changed. While LSP violations are > normally fatal errors (in PHP 8), we could use a lower-severity diagnostic > for this case, that allows code to still run, but makes developers aware of > the problem. (It should be noted that automatic fixup of parameter names > using tooling should be fairly easy to implement.)
I think we should have a notice for now, and eventually when people are used to it upgrade it to an error. > The larger problem is that internal functions don't have a well-defined > concept of parameter default value. Parameter defaults are implicit in C > code, and sometimes based on argument count checks. When named parameters > are involved, one generally cannot assume that if a later (optional) > parameter is passed, all earlier (optional) parameters are passed as well. IIRC I did some work on that when making the skipped parameter RFC, but I think we have no choice but to make all internal functions we control have proper default implementation. Older modules may be lagging though, so another option would be to add some kind of flag to internal functions that would block named parameters if not set, and make extension writers fix their functions and then set this flag explicitly. Of course we'll set this flag for all functions in core, after fixing those of them that need fixing. Maybe not a flag but using different macro/API function, etc. - the idea is that some explicit change would be needed. Yes, that means additional work... More complicated but milder option would be to only check the flag if there's a "gap" in parameters - but this may have higher learning curve as extension writers wouldn't even know their extension needs work until someone skips a parameter. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
