Hi Christoph and Rowan (your replies kind of overlap),
On Thu, Apr 23, 2020 at 12:21 PM Christoph M. Becker <cmbecke...@gmx.de> wrote:
>
> On 23.04.2020 at 11:26, Guilliam Xavier wrote:
>
> > On Wed, Apr 22, 2020 at 11:10 PM Barney Laurance <bar...@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.coll...@gmail.com> wrote:
>
> > On Wed, Apr 22, 2020 at 11:10 PM Barney Laurance <bar...@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.xav...@gmail.com>, "Côme Chilliet"
<come.chill...@fusiondirectory.org>
Cc: internals@lists.php.net
From: Barney Laurance <bar...@redmagic.org.uk>
Message-ID: <663b9713-ad05-47de-3efe-9343cc609...@redmagic.org.uk>
In-Reply-To:
<CAC5V6giDeRAFet5K+=+q9wkykjuwsqdzegutuckwtrvuz88...@mail.gmail.com>
> On Thu, 23 Apr 2020 at 10:26, Guilliam Xavier <guilliam.xav...@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?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
