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

[Bishop Bettini]

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
 is a music video. Neither
seems productive to the PHP community.

Am I missing something?

Re: [PHP-DEV] Mixed type-hint

[Marcos Passos]

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 no type-hint at all.
>
> Regards,
> Robert Korulczyk
>
> W dniu 08.02.2019 o 15:54, Marcos Passos pisze:
> > Those cases should be handled with runtime validation, there is no
> reason for changing the concept of mixed.
> >
> > On Fri, Feb 8, 2019 at 12:39 Robert Korulczyk  > wrote:
> >
> > > 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 is just example when mixed type-hint may work as actual
> type-hint, not
> > just replacement for PHPDoc or equivalent of... nothing.
> >
> >
> >
> > Regards,
> > Robert Korulczyk
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>

Re: [PHP-DEV] Mixed type-hint

[Robert Korulczyk]

> 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 
is just example when mixed type-hint may work as actual type-hint, not
just replacement for PHPDoc or equivalent of... nothing.



Regards,
Robert Korulczyk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Mixed type-hint

[Dan Ackroyd]

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
discussion of an RFC.

Please can everyone wait until the author of the the RFC has finished
writing it, before saying that it's wrong?

cheers
Dan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Mixed type-hint

[Girgias]

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 fact that `mixed` includes
`null`, would it make more "sense" that `null` is not included, probably,
also even if I do like the proposal it seems this is just to add a
type-hint so you can *mostly* type hint all function.
But in this regards I would prefer that the scalar RFC type hint goes back
into discussion as it has potentially more use case IMHO.

Best regards

George P. Banyard

Re: [PHP-DEV] Mixed type-hint

[Marco Pivetta]

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 for usages of `mixed|null`, which is currently
normalised to `mixed` by existing static analysis tooling (psalm, phpstan).

Even then, by adding a non-nullable almost-top-type doesn't seem helpful:
"here's something random, just make sure it isn't null". That's something
more interesting for an eventual union type RFC (revival?).

Could you clarify on a use-case for changing the semantics of `mixed`?

>

Re: [PHP-DEV] Mixed type-hint

[Robert Korulczyk]

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 all. See 
> https://en.wikipedia.org/wiki/Top_type
> 
> On Fri, 8 Feb 2019, 12:45 Robert Korulczyk   wrote:
> 
> 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
> >     > 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 is not very 
> pragmatic - mixed could be used to disallow null, so it will actually work
> for type
> >     check.
> >
> >
> >
> >     Regards,
> >     Robert Korulczyk
> >
> >     --
> >     PHP Internals - PHP Runtime Development Mailing List
> >     To unsubscribe, visit: http://www.php.net/unsub.php
> >
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Mixed type-hint

[Marco Pivetta]

`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.
> >
> > On Fri, 8 Feb 2019, 12:21 Robert Korulczyk  rob...@korulczyk.pl> wrote:
> >
> > > 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 is not very
> pragmatic - mixed could be used to disallow null, so it will actually work
> for type
> > check.
> >
> >
> >
> > Regards,
> > Robert Korulczyk
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>

Re: [PHP-DEV] Mixed type-hint

[Robert Korulczyk]

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
> > 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 is not very 
> pragmatic - mixed could be used to disallow null, so it will actually work 
> for type
> check.
> 
> 
> 
> Regards,
> Robert Korulczyk
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Mixed type-hint

[Marco Pivetta]

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 it was no type-hint at all...
>
> Another thing is that including null as part of mixed is not very
> pragmatic - mixed could be used to disallow null, so it will actually work
> for type
> check.
>
>
>
> Regards,
> Robert Korulczyk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Mixed type-hint

[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 it was no type-hint at all...

Another thing is that including null as part of mixed is not very pragmatic - 
mixed could be used to disallow null, so it will actually work for type
check.



Regards,
Robert Korulczyk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Nikita Popov]

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. Use
> with care" - and the pcre author raised concern about PHP enabling this by
> default (see https://bugs.exim.org/show_bug.cgi?id=2362 ).
>
> I agree and I'd like to propose to disable this in the next major version.
> The existing modifier to disable this (X - PCRE_EXTRA) can be removed as
> well. Would this require an RFC ?
>

This change sounds reasonable and I don't think it needs an RFC if there
are no disagreements on list.

Nikita

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

[Sjon Hortensius]

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 enabling this by
default (see https://bugs.exim.org/show_bug.cgi?id=2362 ).

I agree and I'd like to propose to disable this in the next major version.
The existing modifier to disable this (X - PCRE_EXTRA) can be removed as
well. Would this require an RFC ?

Cheers,
Sjon

RE: [PHP-DEV] VOTE abolish narrow margins

[Zeev Suraski]

> -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-margins

Reasons I voted 'no':

- This is clearly rushed.  A more comprehensive RFC is in the works and already 
under discussion.
- Substantial changes were made last minute, without allowing reasonable time 
to discuss, or for people to even acquaint themselves with the changes.  As an 
RFC that deals with process, that's an extremely bad precedent.
- It places strong bias for status quo even in cases where one does not exist.
- It does not tackle the voting eligibility issues we have.

The general idea is good, the implementation & surrounding process are bad.

Zeev


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Nikita Popov]

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-insensitive constants.
> >>
> >> https://wiki.php.net/rfc/case_insensitive_constant_deprecation
> >>
> >> If you missed the discussion for this RFC, you can read up on it here:
> >>
> >> https://externals.io/message/102389
> >>
> >> As this is a language change, the vote requires a 2/3 supermajority. The
> >> vote will be open until 2018-07-09.
> >>
> >
> > I'm happy to announce that this RFC has been accepted unanimously with 39
> > votes in favor and 0 against.
>
> I just learned that com_load_typelib()[1] automatically registers enum
> members as constants, and allows to register them as case-insensitive
> (the default is case-sensitive, despite the documentation, which I'm
> going to fix right away).  If a typelib is implicitly loaded,
> com.autoregister_casesensitive[2] controls whether constants are
> registered case-sensitively or not.  It seems to me com_load_typelib()
> should trigger a deprecation warning, if FALSE is passed as second
> argument, and also disabling com.autoregister_casesensitive should.
>
> Can this be amemded for PHP 7.3.3, or are there any objections?
>
> [1] 
> [2]
> <
> http://php.net/manual/en/com.configuration.php#ini.com.autoregister-casesensitive
> >
>

Thanks for pointing this out! Agree that both of those should be deprecated
... in fact the necessary for code handling case-insensitive constants is
already gone in master, so they'll definitely have to go as well.

Personally I think it would be best to add the deprecations in 7.4, as
there's no particular rush and we usually don't add deprecations in patch
releases. I don't have a problem with them being added in 7.3.3 either
though, this is not exactly prime functionality and we're early in the
release cycle...

Nikita

[PHP-DEV] VOTE abolish narrow margins

[Joe Watkins]

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

[BohwaZ/PHP]

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 weird :)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php