[PHP-DEV] What's up with github.com/php-src?

Having mistakenly cloned php-src/php instead of php/php-src (again), I figured I'd ask -- is php-src used for anything? The code seems to be quite old, and the content of php-src/php-src.github.io

Re: [PHP-DEV] Mixed type-hint

It is just a (draft) proposal. Anyway, the RFC does not force you to declare a mixed type but brings an option for who wants to. On Fri, Feb 8, 2019 at 13:03 Robert Korulczyk wrote: > There is no reason to introduce `mixed` type-hint if it does not provide > any validation and works the same as

Re: [PHP-DEV] Mixed type-hint

> Could you clarify on a use-case for changing the semantics of `mixed`? For example storage which does not allow to store null. Like simple cache which treats null as "miss", so it is not able to cache null as value. Obviously it is not a deal breaker and use case is quite rare anyway, but this

Re: [PHP-DEV] Mixed type-hint

On Fri, 8 Feb 2019 at 07:20, Rasmus Schultz wrote: > > Regarding the mixed type-hint RFC: > > https://wiki.php.net/rfc/mixed-typehint The status of the RFC is in "In Draft" and you don't appear to be the author of the RFC. It is not appropriate for someone other than the author to start the disc

Re: [PHP-DEV] Mixed type-hint

On Fri, 8 Feb 2019 at 13:13, Robert Korulczyk wrote: > Sounds like an arbitrary interpretation. Treating `?mixed" as "top type" > (including null) would be more practical and consistent with other > type-hints. > > Regards, > Robert Korulczyk > The whole PHP Documentation is based around the fac

Re: [PHP-DEV] Mixed type-hint

On Fri, 8 Feb 2019, 13:13 Robert Korulczyk Sounds like an arbitrary interpretation. Treating `?mixed" as "top type" > (including null) would be more practical and consistent with other > type-hints. > The PHP ecosystem (libraries) already uses `mixed` as a type including `null`. You can survey fo

Re: [PHP-DEV] Mixed type-hint

Sounds like an arbitrary interpretation. Treating `?mixed" as "top type" (including null) would be more practical and consistent with other type-hints. Regards, Robert Korulczyk W dniu 08.02.2019 o 12:47, Marco Pivetta pisze: > `mixed` is the "top" type, which means that it contains anything at

Re: [PHP-DEV] Mixed type-hint

`mixed` is the "top" type, which means that it contains anything at all. See https://en.wikipedia.org/wiki/Top_type On Fri, 8 Feb 2019, 12:45 Robert Korulczyk What definition? > > Regards, > Robert Korulczyk > > W dniu 08.02.2019 o 12:37, Marco Pivetta pisze: > > Mixed includes null by definition

Re: [PHP-DEV] Mixed type-hint

What definition? Regards, Robert Korulczyk W dniu 08.02.2019 o 12:37, Marco Pivetta pisze: > Mixed includes null by definition. > > On Fri, 8 Feb 2019, 12:21 Robert Korulczyk wrote: > > > Without this, the mixed type-hint is basically meaningless noise, is it >

Re: [PHP-DEV] Mixed type-hint

Mixed includes null by definition. On Fri, 8 Feb 2019, 12:21 Robert Korulczyk > Without this, the mixed type-hint is basically meaningless noise, is it > > not? About as effective is a doc-block? > > This mixed type seems to be meaningless by design since its main goal is > to work the same as if

Re: [PHP-DEV] Mixed type-hint

> Without this, the mixed type-hint is basically meaningless noise, is it > not? About as effective is a doc-block? This mixed type seems to be meaningless by design since its main goal is to work the same as if it was no type-hint at all... Another thing is that including null as part of mixed

Re: [PHP-DEV] pcre: shouldn't pass BAD_ESCAPE_IS_LITERAL by default

On Fri, Feb 8, 2019 at 11:57 AM Sjon Hortensius wrote: > Hi internals, > > PHP enables bad_escape_is_literal by default when using pcre methods - this > results in invalid escape-patterns (such as \i) being interpreted as a > literal `i`. This option is documented in pcre as "a dangerous option.

[PHP-DEV] pcre: shouldn't pass BAD_ESCAPE_IS_LITERAL by default

Hi internals, PHP enables bad_escape_is_literal by default when using pcre methods - this results in invalid escape-patterns (such as \i) being interpreted as a literal `i`. This option is documented in pcre as "a dangerous option. Use with care" - and the pcre author raised concern about PHP enab

RE: [PHP-DEV] VOTE abolish narrow margins

> -Original Message- > From: Joe Watkins > Sent: Friday, February 8, 2019 10:51 AM > To: PHP internals > Subject: [PHP-DEV] VOTE abolish narrow margins > > Morning all, > > As promised, abolish narrow margins is now open for voting: > > https://wiki.php.net/rfc/abolish-narrow-margin

[PHP-DEV] Re: [VOTE] Deprecate and remove case-insensitive constants

On Thu, Feb 7, 2019 at 11:31 PM Christoph M. Becker wrote: > On 16.07.2018 at 19:00, Nikita Popov wrote: > > > On Mon, Jul 9, 2018 at 10:36 AM, Nikita Popov > wrote: > > > >> I would like to open the vote on the RFC for the deprecation (in PHP > 7.3) > >> and removal (in PHP 8.0) of case-insensi

[PHP-DEV] VOTE abolish narrow margins

Morning all, As promised, abolish narrow margins is now open for voting: https://wiki.php.net/rfc/abolish-narrow-margins Cheers Joe

Re: [PHP-DEV] New website for the PHP project

Could not find anything about PDOStmt::setParam either, but I fixed it for you: http://php.net/pdostatement_bindparam You're welcome ;) Ah ah good catch :) I meant bindParam obviously ^^ The fact is http://php.net/bindparam will return nothing about PDOStatement::bindParam which is kind of wei