> Le 29 janv. 2020 à 22:11, Bishop Bettini <bis...@php.net> a écrit : > > On Wed, Jan 29, 2020 at 3:12 PM Claude Pache <claude.pa...@gmail.com > <mailto:claude.pa...@gmail.com>> wrote: > > >> Le 29 janv. 2020 à 19:42, Bishop Bettini <bis...@php.net >> <mailto:bis...@php.net>> a écrit : >> >> Cons... have to enumerate everything, potentially lots of work to do that >> to update old code to use; edge cases I'm not thinking about. > > > Not only it is much work (although it could be partially automated), but it > does not make much sense. > > I’ve taken a random file (~650 LoC) in the codebase I’m working on. With > `declare(strict_qualify=1)`, I would have to add: > > use function > array_filter > , array_flip > , array_key_exists > , array_keys > , array_push > , array_unshift > , compact > , ctype_digit > , idate > , in_array > , is_int > , is_string > , ksort > , ob_get_clean > , ob_start > , preg_match > , sprintf > , strlen > , strncmp > , substr_count > , trim > , usort; > > A fair critique. Under the "goad use of wildcard import" pro, the quick way: > use \{*};
As of today, we already have something like `use function *`. We name it “fallback to the global scope”. The current RFC proposes an alternative approach, with its own advantages and inconveniences. > > > Second, and I find this the best reason, that enumeration tells me quite a > bit about what that code does. I don't need to see the code to know that it's > compute oriented, doesn't touch resources (eg files), and is doing what PHP > does best: string and array manipulation. It also shows me that code's doing > output buffer manipulation, which seems out of place and suggests that should > be refactored out. > > IOW, it's a really nice abstract / summary of what the code's doing. And > that's some very good insight. It’s an illusion: the enumeration of used global functions doesn’t say all. For instance, you cannot guess if the code writes on the filesystem by manipulating an instance of `SplFileObject` (or some other custom class), or not. —Claude
