Re: Resurrecting named parameters

Le mardi 7 avril 2020, 14:44:38 CEST Nikita Popov a écrit : > 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. > > While it is possible (but rather challenging) to make things work mostly > transparently with current ZPP, some functions do need to adjusted to > support named parameters, and may cause misbehavior/crashes if they are > not. As a rule of thumb, functions that make non-trivial use of > ZEND_NUM_ARGS() are affected. This is something we can address for > functions in bundled extensions, but may also affect 3rd-party extensions. > > I think that ideally, we'd deal with internal functions the same way we do > for userland functions, by relying on default values that are part of the > function declaration. As part of the PHP stub work, we now have information > on default values in stub files, but this information is currently not > available to the engine. This is a more general problem with internal functions which bugs me a lot. They can behave in a different way when not providing an attribute and when providing the default value. We should aim to make them behave exactly as a userland function with the same stub, no? -- Côme Chilliet FusionDirectory - https://www.fusiondirectory.org