Re: Re: [PHP-DEV] [RFC] Mixed type

Hi Christoph and Rowan (your replies kind of overlap), On Thu, Apr 23, 2020 at 12:21 PM Christoph M. Becker <cmbecker69@gmx.de> wrote: > > On 23.04.2020 at 11:26, Guilliam Xavier wrote: > > > On Wed, Apr 22, 2020 at 11:10 PM Barney Laurance <barney@redmagic.org.uk> wrote: > > > >> Taking a random example, arguments to str_replace documented as mixed > >> accept string|array and not anything else. > > > > Indeed, > > <https://www.php.net/manual/en/language.pseudo-types.php#language.types.mixed> > > currently says that, in the PHP documentation, "mixed > > indicates that > > a parameter may accept multiple (but not necessarily all) types", and > > gives two examples: > > <https://www.php.net/manual/en/function.gettype.php> > > is accurate, but > > > > <https://www.php.net/manual/en/function.str-replace.php> IMO > > should > > just use string|array rather than > > mixed (that's already the case > > in > > <https://github.com/php/php-src/blob/master/ext/standard/basic_functions.stub.php#L649-L655>). > > Besides that PhD does not yet properly support union types[1], it's not > quite as simple. array|string would cause failure in strict mode if, > for instance, an int is passed; however, str_replace() has no issues > with this[2]. This is the reason why the stub file declares the types > of $search and $replace only in the doc block comment. > > [1] <https://github.com/php/phd/pull/25> > [2] <https://3v4l.org/R7Iac> Thanks for the clarification (and your PRs!). I guess internal functions can be "fuzzy" :/ On Thu, Apr 23, 2020 at 12:33 PM Rowan Tommins <rowan.collins@gmail.com> wrote: > > > On Wed, Apr 22, 2020 at 11:10 PM Barney Laurance <barney@redmagic.org.uk> > wrote ... > > I don't seem to have this message, and can't find it in any archives; was > it sent off-list by mistake? I don't know why Barney's email didn't make it to the list... In my box, it seems to have correct headers, notably: Subject: Re: Re: [PHP-DEV] [RFC] Mixed type To: Guilliam Xavier <guilliam.xavier@gmail.com>, "Côme Chilliet" <come.chilliet@fusiondirectory.org> Cc: internals@lists.php.net From: Barney Laurance <barney@redmagic.org.uk> Message-ID: <663b9713-ad05-47de-3efe-9343cc609abc@redmagic.org.uk> In-Reply-To: <CAC5V6giDeRAFet5K+=+q9WkykjuwSqdZEgUTuckWtRvUz88YPw@mail.gmail.com> > On Thu, 23 Apr 2020 at 10:26, Guilliam Xavier <guilliam.xavier@gmail.com> > wrote: > > > I'd rather have the docs "fixed" (but I suspect > > str_replace is not > > the only place where mixed is used in an > > "approximate" fashion). > > Don't forget how recent support for union types in PHP itself is; while the > manual could have come up with a richer notation, the invention of "mixed" > is itself simply a convenience to fit the DocBook template. A change to > that convention would need to be discussed with the editors of the manual > (including nuances like "string|bool" vs "string|false", and edge cases > where null is a rare error return), so calling any use of mixed right now > "wrong" is overstating the case. (Note that I didn't use that word ;) and surrounded "fixed" with quotes, but maybe should have said "improved" or "clarified".) Actually there's one precedent of union-like notation in the manual: array|object, but admittedly special-cased (https://www.php.net/manual/en/language.pseudo-types.php#language.types.array-object), and apparently hardly used (I found https://www.php.net/manual/en/mongodb-driver-bulkwrite.update.php as one instance). And you make a valid point about convention change. > It turns out DocBook itself didn't actually have a notation for union types > until Richard Quadling asked for it for future use in the PHP manual; it's > been accepted but would require tooling updates to actually make use of. > See https://news-web.php.net/php.doc/969386777 and > https://github.com/docbook/docbook/issues/91 Interesting history, thanks. > All of which is to say, I wouldn't use the conventions used in the manual > as any kind of guide to type system design. The best we can say is that > there's existing usage of "mixed" in the PHP manual and in docblocks > understood by many tools, so to avoid confusion, the new pseudo-type should > either behave roughly in line with that usage, or have a new name I concur (but I can't think of a different definition that would work with LSP, and this name is already soft-reserved waiting to be used). So, do you agree that the RFC is fine as is?