Re: [PHP-DEV] Consider removing autogenerated files from tarballs

[Bob Weinand]

On 29.3.2024 23:31:26, Daniil Gentili wrote:
In light of the recent supply chain attack in xz/lzma, leading to a 
backdoor in openSSH 
(https://www.openwall.com/lists/oss-security/2024/03/29/4), I believe 
that it would be a good idea to remove the huge attack surface offered 
by the pre-generated autoconf build scripts and lexers, offered in the 
release tarballs.


In particular, the xz supply chain attack injected the exploit with a 
few obfuscated lines, manually added to the end of the pre-generated 
configure script, that was only bundled in the tarballs.


Even if the exploits themselves were committed to the repo in the form 
of test files, the code that actually injected the exploit in the 
library was not committed to the repo, and was only present in the 
pre-generated configure script in the tarball: this injection mode 
makes sense, as extra files in the tarball not present in the git repo 
would raise suspicions, but machine-generated configure scripts 
containing hundreds of thousands of lines of code not present in the 
upstream VCS are the norm, and are usually not checked before execution.


Specifically in the case of PHP, along from the configure script, the 
tarball also bundles generated lexer files which contain actual C 
code, which is an additional attack vector, i.e. here's the diff 
between the tarball of the 8.3.4 release, and the PHP-8.3.4 tag on the 
git repo:


```
~ $ diff -r php-8.3.4 php-src -q
Only in php-src: 
.git  Files 
php-8.3.4/NEWS and php-src/NEWS differ   
Files php-8.3.4/Zend/zend.h and php-src/Zend/zend.h 
differ Only in php-8.3.4/Zend: zend_ini_parser.c

Only in php-8.3.4/Zend: zend_ini_parser.h
Only in php-8.3.4/Zend: 
zend_ini_parser.output Only in 
php-8.3.4/Zend: zend_ini_scanner.c

Only in php-8.3.4/Zend: zend_ini_scanner_defs.h
Only in php-8.3.4/Zend: 
zend_language_parser.c Only in 
php-8.3.4/Zend: zend_language_parser.h 
Only in php-8.3.4/Zend: zend_language_parser.output

Only in php-8.3.4/Zend: zend_language_scanner.c
Only in php-8.3.4/Zend: 
zend_language_scanner_defs.h   Only in php-8.3.4: 
configure   Files 
php-8.3.4/configure.ac and php-src/configure.ac differ   
Only in php-8.3.4/ext/json: 
json_parser.tab.c  Only in 
php-8.3.4/ext/json: json_parser.tab.h

Only in php-8.3.4/ext/json: json_scanner.c
Only in php-8.3.4/ext/json: 
php_json_scanner_defs.h    Only in 
php-8.3.4/ext/pdo: pdo_sql_parser.c
Only in php-8.3.4/ext/phar: 
phar_path_check.c  Only in 
php-8.3.4/ext/standard: url_scanner_ex.c

Only in php-8.3.4/ext/standard: var_unserializer.c
Only in php-8.3.4/main: php_config.h.in
Files php-8.3.4/main/php_version.h and php-src/main/php_version.h 
differ   Only in php-8.3.4/pear: 
install-pear-nozlib.phar   Only in 
php-8.3.4/sapi/phpdbg: phpdbg_lexer.c  
Only in php-8.3.4/sapi/phpdbg: 
phpdbg_parser.c Only in 
php-8.3.4/sapi/phpdbg: phpdbg_parser.h

Only in php-8.3.4/sapi/phpdbg: phpdbg_parser.output
```

To prevent attacks from malevolent/compromised RMs, I propose 
completely removing all autogenerated files from the release tarballs, 
and ensuring their content exactly matches the content of the 
associated git tag (this means also removing the -dev prefix from the 
version number in main/php_version.h, Zend/zend.h, configure.ac and 
NEWS in the git tag).


Of course this means that users will have to generate the build 
scripts when compiling PHP, as when installing PHP from the VCS repo.


I'm sending a copy of this email to secur...@php.net as well.


Hey Daniil,

You can also have a public CI (i.e. a github action) generate the 
artifacts, along with hash computation.
It should be a github action which runs on tags. This makes it fully 
verifiable; i.e. the code for the generation of action, including the 
hash. Anyone who wants can trivially trace this back.


There's nothing in the tarballs which cannot be trivially automated and 
made verifiable.


I don't think providing pre-generated files is fundamentally flawed, the 
primary lacking thing is verifiability. Which is also what enabled the 
xz backdoor.


Bob

Re: [PHP-DEV] Re: [RFC] [Discussion] [VOTE] Rounding Integers as int

[Bob Weinand]

Hey Marc,

On 18.3.2024 08:53:01, Marc Bennewitz wrote:

Hi Bob,

On 17.03.24 14:59, Bob Weinand wrote:

On 17.3.2024 13:23:04, Marc Bennewitz wrote:

Hello internals,

I have opened the vote for the "Rounding Integers as int" RFC:
https://wiki.php.net/rfc/integer-rounding

Do to Easter weekend the vote will run for two weeks and two days 
until Tue the 2nd of April 2024.


Best regards,

Marc Bennewitz


Hey Marc,

I've voted no; it should be just changed without any force_float 
parameter. Just always return int when possible (and the input was int).
If users wish to have the old behaviour, they should just explicitly 
cast via (float).


The effective BC break of that would be quite small if some things 
which return float today now would return int. I cannot imagine many 
cases where this would actually be unwanted. And as said, explicit 
(float) casts are always possible.


I also dislike force_float, as it cannot just be added to a function 
in any code which shall be backwards compatible to 8.3 and older. It 
would just emit Uncaught Error: Unknown named parameter $force_float.


Changing the return type from float to int is a non trivial quite hard 
to find behavior change.


Imaging code like this:

$x = 800;
$y = 800;
round($x/$y) === 1.0;

This will return false instead of true especially because we teach 
users to use strict comparison.

Such behavior change should be done in a major version.


I see, here we disagree:
- Strict comparison should be avoided when working with numbers. Strict 
comparisons are generally for strings and booleans.

- There's no reason to artificially wait years here.

With the additional parameter it's possible to opt-in into the new 
behavior already in 8.4 while in PHP 9.0 the default behavior will 
change but previously opted in code does not need to get touched again.


Just changing the behavior means waiting for PHP 9.0 without a way to 
opt-in in 8.4 already. If you are not interested in opting in in 8.4 
already you can just ignore the additional argument as this will be 
the default in 9.0.
I'm not interested in having an additional parameter I have to carry 
forward for quite some years.
To mimic the previous behavior in a fully BC way it's as simple as 
explicitly casting the value to float.


I would rather have preferred to see a static analysis solution how 
often round()ed results are compared strictly, assess the actual BC 
impact and possibly encourage tools like Rector to recognize such patterns.




Bob


Regards,
Marc


Bob

[PHP-DEV] Re: [RFC] [Discussion] [VOTE] Rounding Integers as int

[Bob Weinand]

On 17.3.2024 13:23:04, Marc Bennewitz wrote:

Hello internals,

I have opened the vote for the "Rounding Integers as int" RFC:
https://wiki.php.net/rfc/integer-rounding

Do to Easter weekend the vote will run for two weeks and two days 
until Tue the 2nd of April 2024.


Best regards,

Marc Bennewitz


Hey Marc,

I've voted no; it should be just changed without any force_float 
parameter. Just always return int when possible (and the input was int).
If users wish to have the old behaviour, they should just explicitly 
cast via (float).


The effective BC break of that would be quite small if some things which 
return float today now would return int. I cannot imagine many cases 
where this would actually be unwanted. And as said, explicit (float) 
casts are always possible.


I also dislike force_float, as it cannot just be added to a function in 
any code which shall be backwards compatible to 8.3 and older. It would 
just emit Uncaught Error: Unknown named parameter $force_float.


Bob

Re: [PHP-DEV] [RFC] [Discussion] nameof

[Bob Weinand]

> Am 14.01.2024 um 23:58 schrieb Robert Landers :
> 
> Hello Internals,
> 
> After much thought and deliberation, I've updated the nameof RFC
> (https://wiki.php.net/rfc/nameof) to reflect most of this discussion
> and refine a few edge cases regarding objects. TL;DR: there are a few
> rules regarding how properties of objects are addressed that I hope a
> few people will like (and would make it much more usable in static
> contexts, like attributes).
> 
> I'm still not fully settled on the syntax, and this is still very much
> a work in progress. So, I'd love feedback in that regard.
> 
> Robert Landers
> Software Engineer
> Utrecht NL

Hey Robert,

In line with ::class, nameof() should never prepend a leading slash.

The leading slash is a compile time concept to distinguish namespace relative 
and global addressing. At runtime everything has a canonical name, without 
leading slash.

Also prepending a slash in code, i.e. '\\'. is much easier than substr(..., 1) 
to remove, if needed.

On the name resolution of things which have a visibility, I wonder whether the 
visibility is checked or not? In e.g. C# it is.

Also, the RFC says a warning will be emitted during compilation. I assume it 
should be rather be the first time the given line is executed at runtime as PHP 
doesn't necessarily have access to all identifiers yet when the code is 
compiled (e.g. referencing something which is included at runtime).
Similarly, how often is static:: checked? On every access? Thanks to late 
static binding it may sometimes exist and sometimes not.

I think parent:: is missing in the list of left-hand allowed exceptions.

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

Re: [PHP-DEV] [VOTE] [RFC] Final-by-default anonymous classes

[Bob Weinand]

> Am 15.01.2024 um 11:57 schrieb Nicolas Grekas :
> 
> Hi Daniil,
> 
> I've opened voting for the final-by-default anonymous classes RFC:
>> https://wiki.php.net/rfc/final_by_default_anonymous_classes
>> 
> 
> I voted against the proposal because as I mentioned in the previous thread
> on the same topic, this is a backward compatibility break that lacks ground
> but will have impact.
> 
> Note that I voted even though I think the vote itself might be "illegal"
> per our policies (neither did 6 months pass, nor does the proposal make
> substantial changes to the previous one, to some definition of
> "substantial"). If the vote itself isn't allowed per this policy, then my
> vote is void of course.
> https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals
> 
> Sorry for being a bit legalist on the topic but principles matter. We have
> policies and this vote is on the edge of two of them. That's a red flag for
> me.
> 
> Nicolas

Hey Nicolas,

I think having a radically different approach to this definitely qualifies as 
substantial.

The previous RFC made final opt-in. This RFC proposes final by default and an 
opt-out, which is something a lot of voters suggested.

Feel free to disagree, though I see here no grounds for disqualifying. This 
rule is here to not have repeated votes with cosmetic changes, to force a vote 
through.

Bob

Re: [PHP-DEV] First-class callable partial application

[Bob Weinand]

> Am 14.03.2023 um 10:16 schrieb Rowan Tommins :
> 
> On 13/03/2023 20:44, Larry Garfield wrote:
>> As has been discussed numerous times, all of the most used array functions 
>> need to be redesigned to work with iterables, and in many cases make more 
>> sense.  That would be a natural time to also revisit parameter order to fit 
>> with whatever partial application syntax was in use.
> 
> 
> It's not just the array functions, though, it's every single function built 
> into PHP, and an even longer list of userland library and framework 
> functions; and there will always be competing reasons for preferring one 
> signature over another. What attracts me about features like PFA is precisely 
> that they let you work in new ways *without* having to rewrite all of that.
> 
> Some more examples of placeholder-first application, from a quick skim 
> through the documentation:
> 
> $escape = htmlspecialchars(?, ENT_XML1);
> $containsAt = str_contains(?, '@');
> $priceFormatter = number_format(?, 2, ',', '.');
> $addSigToFile = file_put_contents(?, $signature, FILE_APPEND);
> $takeOwnership = chown(?, get_current_user());
> $encode = json_encode(?, JSON_THROW_ON_ERROR | JSON_PRESERVE_ZERO_FRACTION);
> $unserialize = unserialize(?, ['allowed_classes' => false]);
> $isLogger = is_subclass_of(?, LoggerInterface::class, false);
> 
> I'm sure I could look through Laravel's documentation, or Symfony's, and find 
> examples there too.
> 
> Regards,
> 
> -- 
> Rowan Tommins
> [IMSoP]

Hey Rowan,

do we actually need *positional* partial application, after a ... token?

Would it not be enough, to simply forbid positional arguments after a ... and 
just allow named arguments? These already have well defined position 
independent semantics.

There may be some desire for a single argument placeholder later on, but this 
can be introduced later, separately.

Bob

Re: [PHP-DEV] PHP code refactoring (was: include cleanup)

[Bob Weinand]

Hey Max and Dmitry,

> Am 28.02.2023 um 23:34 schrieb Dmitry Stogov :
> 
> On Wed, Mar 1, 2023 at 1:21 AM Max Kellermann  wrote:
> 
>> On 2023/02/28 22:31, Dmitry Stogov  wrote:
>>> https://github.com/php/php-src/commit/0270a1e54c0285fa3c89ee2b0120073ef57ab5fa
>> 
>> This kind of change was favored by a supermajority.
>> 
>> You argue that this supermajority vote is irrelevant, and formally it
>> indeed is, but pondering about formalities is kind of ignorant against
>> the now well-known community opinion.
>> 
>>> https://github.com/php/php-src/commit/b98f18e7c3838cf587a1b6d0f033b89e9909c79d
>> 
>> No vote was made on this, therefore this doesn't violate any community
>> rules, does it?
>> 
> 
> Please reread https://wiki.php.net/RFC/voting#voting
> RFC is accepted by a supermajority of the primary vote.
> The secondary votes may be used to make decisions about implementation
> details.
> 
> Thanks. Dmitry.

In this case, while the primary concern of the RFC was rejected, I think it's 
pretty clear, that there was a supermajority for something specific.
I do agree, that the topic, given hat it conflicts with the rules, a mail to 
internals on that topic should have been sent.
I did vote no on that topic, however I still think there was some mandate by 
the community that this is wanted.
I would thus not make too much of a fuss on these grounds about the splitting.

>> 
>> If you think this should be reverted, explain why.
>> 
>>> https://github.com/php/php-src/commit/42577c6b6b7577c57c161ee4a74cb193382bf1e0
>> 
>> Favored by supermajority, see above.
>> 
>>> https://github.com/php/php-src/commit/c7637ed1c03f556c6fb65884cfc5bfea4920b1c7
>> 
>> No vote, no rule violation, see above.

This is no violation and I think Dmitrys tone was a bit too accusing for that. 
But I also strongly disagree with that change.
Let's revert it. Quickly seeing which number is which type is quite valuable 
for debugging.
By now I know most numbers by heart, but most people won't.

>>> https://github.com/php/php-src/commit/371ae12d890f1887f79b7e2a32f808b4595e5f60
>> 
>> As you see in the commit message, this implements an (unwritten) rule
>> cited by Nikita Popov (which is now written as of
>> https://github.com/php/php-src/pull/10630).  I personally don't agree
>> with this rule (there's a thread on this mailing list about it), and I
>> would favor reverting this commit - I only submitted this trying to
>> help with implementing a rule even though I don't agree with it.
>> 
>> If this gets reverted, then https://github.com/php/php-src/pull/10630
>> should be reverted as well.  Again, not my opinion, I'm just trying to
>> help implement somebody else's opinion.

No, it should not. It makes a lot of sense.
It's however not a hard rule, but a guideline.

Applying these changes to ZEND_API though always shall be evaluated with due 
care.
In this specific instance, a fairly new API I think nobody uses yet, it's sort 
of acceptable.
I wouldn't mind reverting it though

>> 
>> Max
>> 


Max, while it's nice to see a couple cleanups in the PHP codebase, I would like 
to ask you to be a bit less quick at moving things around.
There's value in having a codebase evaluate slowly. Obviously not at the cost 
of progress, new features etc..
Keep in mind, that at least extension authors will need to work with the 
php-src codebase of version 8.2 until probably 7 years in the future (basically 
until PHP is EOL on all Linux distributions). They will appreciate not looking 
at a vastly different codebases.
Finally, these sorts of code moves are also making a git blame harder to track 
back.

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

Re: [PHP-DEV] [PHP_DEV] [RFC] Add file_descriptor() function

[Bob Weinand]

> Am 16.01.2023 um 16:01 schrieb G. P. B. :
> 
> Hello internals,
> 
> I would like to start the discussion about the "Add file_descriptor()
> function" RFC:
> https://wiki.php.net/rfc/file-descriptor-function
> 
> This RFC proposes the addition of the file_descriptor() function to
> retrieve the underlying file descriptor of stream if it exists. This is
> useful when interacting with a USB device.
> 
> Best regards,
> 
> George P. Banyard

Hey George,

I like the idea. However two questions:

Why is it its own function and not part of stream_get_meta_data()? (which you 
anyway want to check to ensure that it's the proper stream type)
Why are all resources throwing a TypeError and not only resources which aren't 
streams? I could imagine calling that function to check whether the stream is 
in memory or backed by a fd for example. I'd propose to return a proper 
checkable value like -1 in that case.

Thanks,
Bob

[PHP-DEV] [RFC][Vote] Destructuring Coalesce

[Bob Weinand]

Hey,

I've just opened the vote on the 
https://wiki.php.net/rfc/destructuring_coalesce 
 RFC.

It will end on November 21.

Bob

Re: [PHP-DEV] [RFC] Destructuring Coalesce

[Bob Weinand]

> Am 03.11.2022 um 20:55 schrieb Tim Düsterhus :
> 
> Hi
> 
> On 10/16/22 23:11, Bob Weinand wrote:
>> I've written a small RFC about adding coalesce ability to list() 
>> destructuring.
>> This should enhance the ability to easily, concisely and readably 
>> destructure arrays with default values.
>> https://wiki.php.net/rfc/destructuring_coalesce 
>> <https://wiki.php.net/rfc/destructuring_coalesce>
> 
> Unless I missed anything, all the examples in the RFC deal with *absent* 
> array keys. Can you also add an example where the key is present, but the 
> value is 'null' to make the behavior with regard to that explicit?
> 
> Best regards
> Tim Düsterhus

There was actually one line saying ... if  $array[0] is null or does not exist, 
but I've added a more specific example under use cases.

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

Re: [PHP-DEV] [RFC] Destructuring Coalesce

[Bob Weinand]

Hey,

> Am 16.10.2022 um 23:56 schrieb David Rodrigues :
> 
> I like it!
> 
> But what should happen if:
> 
> [ $a ?? '123', $b ] = [];

$a is assigned 123, $b emits undefined key error.

> [ $a ?? '123', $b ] = [ 1 ];

$a is assigned 1, $b emits undefined key error.

> [ $a ?? '123', $b ] = [ 1, 2 ];

$a is assigned 1, $b is assigned 2.

> It also supports ?: operator?
> 
> [ $a ?: '123' ] = []; so $a = '123'
> [ $a ?: '123' ] = [ false ]; so $a = '123'
> [ $a ?: '123' ] = [ 456 ]; so $a = 456

?: is out of scope of this RFC; a future RFC may want to take care of that.

Bob

Re: [PHP-DEV] [RFC] Destructuring Coalesce

[Bob Weinand]

> Am 16.10.2022 um 23:11 schrieb Bob Weinand :
> 
> Hey,
> 
> I've written a small RFC about adding coalesce ability to list() 
> destructuring.
> 
> This should enhance the ability to easily, concisely and readably destructure 
> arrays with default values.
> 
> https://wiki.php.net/rfc/destructuring_coalesce 
> <https://wiki.php.net/rfc/destructuring_coalesce>
> 
> Bob

Hey, 

Given  haven't heard much feedback, I'll open the vote by end of the week,

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

[PHP-DEV] [RFC] Destructuring Coalesce

[Bob Weinand]

Hey,

I've written a small RFC about adding coalesce ability to list() destructuring.

This should enhance the ability to easily, concisely and readably destructure 
arrays with default values.

https://wiki.php.net/rfc/destructuring_coalesce 


Bob

Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion

[Bob Weinand]

Hey Mark,

For me, there's a fundamental shortcoming of this proposal:
- You cannot opt out.

Currently, as you describe in your RFC, it is perfectly possible, to opt into 
making this category of errors fail hard (throw an exception in an error 
handler).

However, should your RFC pass, it is not possible to say "hey, I generally 
consider this a low impact class of errors, please try to continue".

As such, given that PHP is meant to appeal to a broad class of use cases, I am 
strongly against this change as proposed.

Bob

> Am 18.02.2022 um 00:28 schrieb Mark Randall :
> 
> Internals,
> 
> Following on from my previous thread, I think we are now in a position where 
> we can begin formal discussions on an RFC to promote undefined variables to 
> Error exceptions in PHP 9.0.
> 
> I present:
> 
> https://wiki.php.net/rfc/undefined_variable_error_promotion
> 
> I still intend to bring other error promotions forward, potentially in 
> collaboration with other developers, but as this is the biggest change, and 
> the most likely to attract a large number of comments, I thought it deserving 
> of a standalone RFC.
> 
> Mark Randall
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Bob Weinand]

> Am 03.01.2022 um 01:13 schrieb Jordan LeDoux :
> 
> Hello internals,
> 
> I've opened voting on
> https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will
> close on 2022-01-17.
> 
> To review past discussions on this RFC and the feature in general, please
> refer to:
> 
> - https://externals.io/message/116611 | Current RFC discussion
> - https://externals.io/message/115764 | Initial RFC discussion
> - https://externals.io/message/115648 | Pre-RFC discussion and fact-finding
> 
> Jordan

Hey Jordan,

thanks for bringing it up to a vote.

I've voted for an inclusion, for the primary reason, that in general, it does, 
in fact, not get abused too much.

It seems to me, that many of the no-voters fear codebases riddled with random 
operator overloads where they make no sense.
I don't share that sentiment. Yes, there will always be some outliers, but it 
shouldn't hinder the general improvement it brings to readability and 
expressiveness. (I strongly disagree that gmp overloads are a net negative.)

For my part, I have had a positive experience with operator overloads in C#. 
They tend to not be overused, make Vector operations graspable (once you have a 
mental model of what vector operations feel and look like…).
In the past I've really hated writing, and especially reading math heavy code 
on something different than the standard euclidean space in PHP. (Vectors, 
complex numbers, integer spaces with a finite size…)
I truly hope this RFC passes, so that these abominations of nested math calls 
may disappear.

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

Re: [PHP-DEV] [RFC] Locale-independent case conversion

[Bob Weinand]

> Am 04.10.2021 um 12:08 schrieb Nikita Popov :
> 
> On Thu, Sep 23, 2021 at 8:32 AM Tim Starling  >
> wrote:
> 
>> Please consider my RFC for locale-independent case conversion.
>> 
>> https://wiki.php.net/rfc/strtolower-ascii
>> https://github.com/php/php-src/pull/7506
>> 
>> The RFC and associated PR ended up going some way beyond the original
>> scope, because for consistency, it's best if everything has the same
>> concept of case folding. I saw this as an opportunity to clean up a
>> common kind of locale-dependence in PHP which was previously inconsistent.
>> 
>> So not only will strtolower() and strtoupper() become
>> locale-independent, converting only ASCII, but also stristr, stripos,
>> strripos, lcfirst, ucfirst, ucwords, str_ireplace, the array sorting
>> functions with SORT_FLAG_CASE, and array_change_key_case.
>> 
>> Also, I changed a number of internal functions to use ASCII case
>> folding, giving rise to a range of effects in callers throughout the
>> core tree. The effects are all documented in the RFC.
>> 
>> I am proposing that locale-sensitive case conversion be provided with
>> the new names ctype_tolower() and ctype_toupper(). Those names might
>> seem odd at first glance, but they are wrappers for functions in
>> ctype.h and work in a very similar way to the rest of the ctype extension.
>> 
> 
> Hi Tim,
> 
> Thanks for creating this proposal, it looks great!
> 
> I think this is a very beneficial change, and the amount of incorrect
> locale-dependent calls we had just in php-src further convinced me of this:
> We're generally aware of the problem, and we still made this mistake. Many
> times.

I definitely agree that it's good to make these functions locale-insentive.

> The only open question I have is regarding the ctype_* functions. One might
> argue that these functions should be locale-independent as well. Certainly,
> whenever I have used ctype_digit() I only intended it to match [0-9]. It
> seems like some people try to use ctype_alpha() in a locale-sensitive way (
> https://stackoverflow.com/questions/19929965/php-setlocale-not-working-for-ctype-alpha-check
>  
> )
> and then fail because it doesn't support UTF-8.

On that topic, do we also want to add mb_ucfrist, mb_lcfirst and mb_ucwords?
Then you have also proper local independent functions handling these use cases.

This is only tangentially related to the current RFC, so feel free to ignore 
this.

Bob

Re: [PHP-DEV] [Vote] Pipe operator v2

[Bob Weinand]

Hey Larry,

there's still ongoing discussion on the semantics, and mirroring implementation 
defined semantics from the implementation into the RFC is not the way to go. 
The RFC should discuss reasons of why semantics were chosen and the 
implementation then be decided upon it. Describing it as "design artifact" is 
not okay.
I'm voting no at this point, to force it to be postponed to PHP 8.2 with proper 
thought of what the semantics shall be. Possibly the semantics are fine (I tend 
to disagree with the current ones, but that's rather point for discussion), but 
they are not discussed enough, especially as they only got described in the RFC 
in the last minutes before the vote.

Bob

> Am 06.07.2021 um 19:13 schrieb Larry Garfield :
> 
> I have opened the vote on the Pipe operator RFC:
> 
> https://wiki.php.net/rfc/pipe-operator-v2
> 
> The vote will close on 20 July.
> 
> -- 
>  Larry Garfield
>  la...@garfieldtech.com
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

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

Re: [PHP-DEV] Disable interactive mode (-a) if readline not available

[Bob Weinand]

> Am 12.05.2021 um 10:12 schrieb Nikita Popov :
> 
> Hi internals,
> 
> If the readline extension is enabled, PHP provides an interactive shell
> under -a. If it is not enabled, it falls back to an "interactive mode"
> (yes, the difference between "interactive shell" and "interactive mode" is
> important here). The interactive mode is simply an stdin input, which needs
> to be terminated using Ctrl+D. You can only run one script that way.
> 
> I think the current behavior is quite confusing, because it's really not
> obvious that you ended up in this fallback mode (you need to know the
> difference between "shell" and "mode" in the output) and most people
> wouldn't know what to do with it. The latest instance of this is
> https://bugs.php.net/bug.php?id=81033.
> 
> I think we would be better off disabling -a completely if readline is not
> available, and exit with a helpful error message. I've opened
> https://github.com/php/php-src/pull/6976 to that effect. Does that sound
> reasonable?
> 
> Regards,
> Nikita

Hey Nikita,

yes, please merge that PR, I've been annoyed more than once that the php -a was 
not actually interactive despite a seemingly good message. (and as cmb noted, 
it's effectively identical to bare php without args.)

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

Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`

[Bob Weinand]

Hey Tyson,

> Am 02.02.2021 um 03:35 schrieb tyson andre :
> 
> Hi Bob Weinand,
> 
>>> Am 20.01.2021 um 01:55 schrieb tyson andre :
>>> 
>>> Hi internals,
>>> 
>>> Voting has started on 
>>> https://wiki.php.net/rfc/readline_interactive_shell_result_function
>>> on 2021-01-19, and ends on 2021-02-02.
>>> 
>>> This RFC proposes to dump the results of non-null expressions using 
>>> var_dump/var_export() by default in `php -a` (the interactive shell).
>>> Additionally, this adds a new function 
>>> `readline_interactive_shell_result_function` to the readline PHP module.
>>> This function only affects interactive shells - it can optionally be used 
>>> to set or clear a closure when `extension_loaded('readline') === true`,
>>> but that closure would only be called in interactive shells (i.e. php -a).
>>> (That closure would be called instead of the native implementation with the 
>>> snippet of code that was evaluated and the expression's result,
>>> if a php statement contained a single expression such as `2+2;` or `$x = 
>>> [1,2];` (that could be used as the expression of a return statement)
>>> - Dumping of expression results can be disabled using an ini setting or at 
>>> runtime 
>>> 
>>> Thanks,
>>> - Tyson
>> 
>> Hey Tyson,
>> 
>> My main concern in this iteration of the RFC is: what happens with 
>> big/deeply nested objects?
>> They tend to spew tons of lines if var_dump()'ed. Do we have reasonable 
>> depth/output limitations in default dumping mode?
>> 
>> I'm often enough using php -a to do some quick ad-hoc processing (example, 
>> read a big json file, and then access a value; instantiating a mediawiki bot 
>> framework and calling replace on it; ...).
>> 
>> It's really cool to have any interactive feedback at all, but please, at 
>> least by default, limit the output. (An example is the JS REPL in browser 
>> console - it shows you a minimal preview of the object, and then you can 
>> expand with your mouse. Obviously with a pure cli application, this needs 
>> different - intuitive - navigation.)
>> 
>> As it currently stands, this makes php -a unusable in any but the simplest 
>> cases, without just disabling the whole feature.
>> 
>> I like the whole feature, but the missing output limitation (I have yet 
>> enough nightmares from var_dump()'ing the wrong object filling my shell with 
>> tons of irrelevant information… I don't need that potentially happening on 
>> every single evaluated expression)
>> 
>> Thus I'm voting no, for now.
> 
> As-is, the entire object or string would be dumped with var_export/var_dump 
> to stdout.
> 
> Thoughts on the adding following output truncation mechanism 
> (for the default C result dumper implementation)
> before printing the results of the returned expression 
> (the user output continues to be untruncated, and the existence of cli.pager 
> would not affect this mechanism in case the binary is not actually a pager)?
> For arrays/objects used with var_dump - the equivalent of 
> `ob_start(); var_dump($result); $result = ob_get_clean();` 
> would have to be used first from C since var_dump still writes to the output 
> buffer (php_printf(), etc.)

var_dump() tends to be quite intensive in newline usage. I don't think 
var_dump() (as is) is the best mechanism to print. At least I'd use one 
property/one array argument = single line instead of two lines.
Additionally, when dumping a nested object, it's more valuable to see as much 
as possible from the primary object rather than the deep nesting.


> I'd omitted output truncation from the RFC because I wasn't sure how many 
> people 
> would consider it excessive to include a limit on var_dump output, and there 
> was little feedback before the RFC vote started.

Yeah, sorry for the late comment on that :-)

> The simplest implementation would be to truncate to a byte limit and append 
> `...` if truncated, 
> but the main concern that's been brought up is the approximate number of 
> lines.
> Obviously, there'd be a value in truncating the output if there were to be 
> megabytes of output,
> though exactly what settings make sense as a default would vary.

As mentioned a section earlier, there should be limits according to the 
nesting-level … e.g. if it's the top-level value, a string may have 20 lines 
printed and array and objects as well. And array entries/properties should then 
be in a single line or take up to max ... 20 / count(properties or array 
entries) lines (width before truncation can be determine from terminal width), 
which th

Re: [PHP-DEV] [VOTE] Dump results of expressions in `php -a`

[Bob Weinand]

> Am 20.01.2021 um 01:55 schrieb tyson andre :
> 
> Hi internals,
> 
> Voting has started on 
> https://wiki.php.net/rfc/readline_interactive_shell_result_function
> on 2021-01-19, and ends on 2021-02-02.
> 
> This RFC proposes to dump the results of non-null expressions using 
> var_dump/var_export() by default in `php -a` (the interactive shell).
> Additionally, this adds a new function 
> `readline_interactive_shell_result_function` to the readline PHP module.
> This function only affects interactive shells - it can optionally be used to 
> set or clear a closure when `extension_loaded('readline') === true`,
> but that closure would only be called in interactive shells (i.e. php -a).
> (That closure would be called instead of the native implementation with the 
> snippet of code that was evaluated and the expression's result,
> if a php statement contained a single expression such as `2+2;` or `$x = 
> [1,2];` (that could be used as the expression of a return statement)
> - Dumping of expression results can be disabled using an ini setting or at 
> runtime 
> 
> Thanks,
> - Tyson

Hey Tyson,

My main concern in this iteration of the RFC is: what happens with big/deeply 
nested objects?
They tend to spew tons of lines if var_dump()'ed. Do we have reasonable 
depth/output limitations in default dumping mode?

I'm often enough using php -a to do some quick ad-hoc processing (example, read 
a big json file, and then access a value; instantiating a mediawiki bot 
framework and calling replace on it; ...).

It's really cool to have any interactive feedback at all, but please, at least 
by default, limit the output. (An example is the JS REPL in browser console - 
it shows you a minimal preview of the object, and then you can expand with your 
mouse. Obviously with a pure cli application, this needs different - intuitive 
- navigation.)

As it currently stands, this makes php -a unusable in any but the simplest 
cases, without just disabling the whole feature.

I like the whole feature, but the missing output limitation (I have yet enough 
nightmares from var_dump()'ing the wrong object filling my shell with tons of 
irrelevant information… I don't need that potentially happening on every single 
evaluated expression)

Thus I'm voting no, for now.

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

Re: [PHP-DEV] [RFC] Enumerations, Round 2

[Bob Weinand]

> Am 29.01.2021 um 18:15 schrieb Larry Garfield 
> :
> 
> And we're back again.  The RFC has been updated with a steady stream of 
> smaller improvements based on feedback and testing, and is now in its Final 
> Form(tm) (we think).  The only major change worth noting is that we renamed 
> things. :-)
> 
> An enum with no scalar backing is now called a Pure Enum, made up of Pure 
> Cases.  One that does have backing values is called a Backed Enum, made up of 
> Backed Cases.  That change is mainly to allow for future expansion to 
> non-scalar backing static values, should the use case arise.  Reflection was 
> also reworked a bit to make it more logical.
> 
> https://wiki.php.net/rfc/enumerations 
> 
> At this point, Ilija and I consider the RFC done and ready for a vote.  
> Baring any major issues being brought up, we plan to start the vote in the 
> first half of next week, probably Tuesday-ish.  If you have any other bug 
> reports or tweaks, please speak now or forever hold your patches.

Hey,

There is a single point in the RFC which is unreasonable to me, which is 
barring static properties.
I do not consider static properties to be handled the same than normal 
properties. It's perfectly reasonable to prevent normal instance properties if 
we want [pure] enums to be stateless (which makes sense).
It however does not make sense to arbitrarily restrict static properties. In 
the end a static property (on final classes at least) is mostly a nice way to 
express global state, which could be written "global 
$my_namespaced_enum_class_prop_name;" and used then. It's just that 
self::$prop_name is much more readable and user-friendly, including for types 
and static analysis.

I also agree with Nikitas note that IterableEnum is really a suboptimal name. 
If you want to highlight finiteness, maybe call it FiniteEnum. UnitEnum would 
be fine too.

Thanks,
Bob

> --Larry Garfield
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php 
> 

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

[Bob Weinand]

> Am 24.07.2020 um 16:11 schrieb Benjamin Eberlei :
> 
> On Fri, Jul 24, 2020 at 4:00 PM Chris Riley  wrote:
> 
>> Hi all,
>> 
>> Following up from this I've created a draft RFC:
>> https://wiki.php.net/rfc/renamed_parameters will move to in discussion
>> once
>> I've ensured everything important has been captured.
>> 
>> Regards,
>> Chris
>> 
> 
> You added PHP 8.0 as a propsoed version, but that will not be possible
> anymore 2 weeks of discussion + 2 weeks of voting are not possible to fit
> in before the feature freeze, which is in 11 days.

Hey Benjamin,

While you are technically correct, the primary point of a feature freeze is not 
allowing in completely new features.
It will always happen that there are changes and extensions to RFCs introduced 
for the next version which may need to be addressed first, because there is 
massive benefit to the new feature in that case. (from a backwards/forwards 
compatibility standpoint for example)

I do not necessarily agree with the RFC (not given it much thought yet), but I 
think such RFCs shall still be able to be introduced later on (well, not in RC 
phase, but a bit after the feature freeze cutoff), if there is actual benefit 
from them not being deferred to the next version. Ultimately, the RM has to 
make the call (also to avoid indefinite delays or filibustering or such).

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

Re: [PHP-DEV] [RFC][VOTE] debug_backtrace alternative as an array of StackFrame objects

[Bob Weinand]

> Am 22.07.2020 um 09:10 schrieb Côme Chilliet 
> :
> 
> Le Tue, 21 Jul 2020 13:52:39 +0200,
> Michał Marcin Brzuchalski  a écrit :
>> Voting opened 2020-07-21 and closes 2020-08-04.
>> 
>> Link to the RFC https://wiki.php.net/rfc/stack-frame-class#vote
> 
> Hello,
> 
> Can people voting no explain their vote?
> I did not see that much discussion against this prior to vote.
> 
> (I’m not convinced this should pass either, just wondering what the
> pro/cons are here)
> 
> Côme

Hey,

I guess, the main objection, at least for me, is just introducing a new API, 
just because it looks slightly nicer, but the actual benefit being very 
marginal.

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

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

[Bob Weinand]

> Am 17.07.2020 um 11:30 schrieb Nikita Popov :
> 
> On Fri, Jul 17, 2020 at 11:27 AM Bob Weinand  <mailto:bobw...@hotmail.com>> wrote:
> Hey George,
> 
> while I agree with your RFC in general, changing the autocast behavior of the 
> empty string is not acceptable for me.
> 
> Empty strings often are the output of non-existing things, like default value 
> of a text field in a DB, when reading files not filled with inputs yet etc. 
> It should expose a similar behaviour to all the other falsy values, i.e. 
> null, false, ...
> The current side effects can be held in mind "ah this won't break if the 
> input is unexpectedly not present, should be safe" while writing code, but 
> finding places where that sort of assumption was made is next to impossible.
> This should be a major step backwards from the forgiveness of PHP - 
> especially in cases where "shouldn't happen, but the behaviour is nearly 
> always what I expect, and logging will allow me to improve it".
> I do not want to break everything in production because something happens to 
> return an empty string.
> 
> I'm aware that it is different from the TypeError behavior of *userland* 
> functions (internal functions do only emit a warning). But internal functions 
> are the important foundation here. This is also internal, the number 
> conversions.
> 
> Hence I'm voting no on this.
> 
> Can you give a code example for an undesirable behavior change? I don't think 
> this proposal changes anything about the handling of empty strings. Empty 
> strings are already considered non-numeric, and as such already result in 
> TypeErrors (e.g. https://3v4l.org/WVfeg <https://3v4l.org/WVfeg>).
> 
> Nikita

Apparently I tested the wrong functions. Was having a look at pow() which 
accepts a number.

Sigh. Then it's the fault of pow() and pow() should be probably fixed…

But as an example, I was storing values as a pipe delimited string of counters 
in the db - added a new value and forgot to update the old records. Old records 
looking like "1|27|37|". Doing an list($a, $b, $c, $d) = explode("|", $input); 
worked fine, but $d was, well, an empty string. Quickly found the reason in the 
logs, updated the db, but our end users didn't notice anything.

Bob

Re: [PHP-DEV] [RFC] [VOTE] Saner numeric strings

[Bob Weinand]

Hey George,

while I agree with your RFC in general, changing the autocast behavior of the 
empty string is not acceptable for me.

Empty strings often are the output of non-existing things, like default value 
of a text field in a DB, when reading files not filled with inputs yet etc. It 
should expose a similar behaviour to all the other falsy values, i.e. null, 
false, ...
The current side effects can be held in mind "ah this won't break if the input 
is unexpectedly not present, should be safe" while writing code, but finding 
places where that sort of assumption was made is next to impossible.
This should be a major step backwards from the forgiveness of PHP - especially 
in cases where "shouldn't happen, but the behaviour is nearly always what I 
expect, and logging will allow me to improve it".
I do not want to break everything in production because something happens to 
return an empty string.

I'm aware that it is different from the TypeError behavior of *userland* 
functions (internal functions do only emit a warning). But internal functions 
are the important foundation here. This is also internal, the number 
conversions.

Hence I'm voting no on this.

Bob

> Am 16.07.2020 um 16:18 schrieb G. P. B. :
> 
> Hello internals,
> 
> I've opened voting for the Saner Numeric strings RFC:
> https://wiki.php.net/rfc/saner-numeric-strings
> 
> This will last 2 weeks until the 30th of July
> 
> Best regards
> 
> George P. Banyard

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

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

[Bob Weinand]

> Am 18.06.2020 um 20:24 schrieb Lynn :
> 
> 
> 
> On Thu, Jun 18, 2020 at 3:38 PM Bob Weinand  <mailto:bobw...@hotmail.com>> wrote:
> P.s. And to be honest, I've never heard from a dark-skinned person that they 
> felt actually oppressed by words like blacklist.
> 
> And here my personal opinion, to be taken with a grain of salt: This whole 
> white- and blacklist discussion is mostly "hey I want to make black people 
> feel more welcome, let me call blacklist bad and condemn everyone not 
> agreeing. Then I have done my good deed" - without having any actual impact 
> on the well-being of dark-skinned people. - That's what it feels like for me, 
> but I'm open to being corrected by those who are actually dark-skinned and 
> impacted by it, in which case I'll immediately retract my last sentence.
> 
> Hi Bob,
> 
> Nobody is talking about oppression when it comes to certain "technical" 
> terms. Please look my post from earlier and look at the tweets I link: 
> https://externals.io/message/110515#110574 
> <https://externals.io/message/110515#110574>
> 
> I can recommend everyone to expand their bubble, as a lot of replies in here 
> show that the bubbles are homogeneous.
> 
> Regards,
> Lynn


Hey,

yes, you are making quite the same point than I did. Maybe I misused the word 
_oppression_ here. But in any case, I fully agree with you.

Bob

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

[Bob Weinand]

Hey,

> Am 18.06.2020 um 17:18 schrieb Benas IML :
> 
> Hey Bob,
> 
> Magic methods are **never** supposed to be called directly (even more if that 
> method is a constructor or a destructor). If that's not the case, it's just 
> plain bad code. But by enforcing these rules, we make sure that less of that 
> (bad code) is written and as a result, we make PHP code less bug-prone and 
> easier to debug. That's also most likely the reason why

__construct() is invoked directly on parent calls, sometimes to reinitialize an 
object or after ReflectionClass::newInstanceWithoutConstructor.

I invoke __destruct() directly when needing an early freeing of existing 
resources.

> "ensure magic methods' signature" RFC opted in to validate `__clone` method's 
> signature and ensure that it has `void` return type.
> 
> Just for the sake of making sure that you understand what I mean, here are a 
> couple of examples that show that no magic method is ever supposed to be 
> called directly:
> ```php
> // __toString
> (string) $object;

I like using ->__toString() in favor of (string) casts when the variable is 
guaranteed to be an object to highlight that and avoid magic-ness.

> // __invoke
> $object();

Same here, unless the object is a closure.

> // __serialize
> serialize($object);
> ```

Can't argue much about that one, I never use serialize().

> Moreover, by validating constructors/destructors and allowing an explicit 
> `void` return type declaration, we are becoming much more consistent 
> (something that PHP is striving for) with other magic methods (e. g. 
> `__clone`).

Yeah, __clone() is odd. No idea why.

> Also, saying that "sometimes you have valid information to pass from the 
> parent class" is quite an overstatement. After analyzing most of the 95 
> Composer packages that had a potential BC break, I found out that either they 
> wanted to return early (that is still possible to do using `return;`) or they 
> added a `return something;` for no reason. Thus, no libraries actually 
> returned something useful and valid from a constructor (as they shouldn't).
> 
> Last but certainly not least, constructors have one and only one 
> responsibility - to initialize an object. Whether you read Wikipedia's or PHP 
> manual's definition, a constructor does just that. It initializes. So, the 
> PHP manual is perfectly correct and documents the correct return type that a 
> constructor should have.

It also is generally a bad idea to have side effects in constructors, but 
_sometimes_ it is justified. Only because something mostly is a bad idea, it is 
not always.
Also note that other languages completely forbid manual ctor calls. But PHP 
doesn't (and for good reason, like after using 
ReflectionClass::newInstanceWithoutConstructor).

Bob

> Best regards,
> Benas
> 
> On Thu, Jun 18, 2020, 4:06 PM Bob Weinand  <mailto:bobw...@hotmail.com>> wrote:
> > Am 17.06.2020 um 01:10 schrieb Benas IML  > <mailto:benas.molis@gmail.com>>:
> > 
> > Hey internals,
> > 
> > This is a completely refined, follow-up RFC to my original RFC. Based on the
> > feedback I have received, this PR implements full validation and implicitly
> > enforces `void` rules on constructors/destructors while also allowing to
> > declare an **optional** explicit `void` return type. Note, that there is a
> > small but justifiable BC break (as stated by the RFC).
> > 
> > RFC: https://wiki.php.net/rfc/make_ctor_ret_void 
> > <https://wiki.php.net/rfc/make_ctor_ret_void>
> > 
> > Best regards,
> > Benas Seliuginas
> 
> Hey Benas,
> 
> I do not see any particular benefit from that RFC.
> 
> Regarding what the manual states - the manual is wrong there and thus should 
> be fixed in the manual. This is not an argument for changing engine behaviour.
> 
> Sometimes a constructor (esp. of a parent class) or destructor may be called 
> manually. Sometimes you have valid information to pass from the parent class.
> With your RFC an arbitrary restriction is introduced necessitating an extra 
> method instead.
> 
> In general that RFC feels like "uh, __construct and __destruct are mostly 
> void, so let's enforce it … because we can"?
> 
> On these grounds and it being an additional (albeit mostly small) unnecessary 
> BC break, I'm not in favor of that RFC.
> 
> Bob

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

[Bob Weinand]

> Am 18.06.2020 um 00:36 schrieb Jakob Givoni :
> To repeat what has been said many times over now: It's when "black" is
> associated with "bad" in a composite term like "blacklist" we should
> consider being considerate of a group of people who actually have skin
> of that color.
> 
> Best,
> Jakob


TL;DR: Can we please do terminology changes for the right reasons, just like 
the RFC itself is proposing. Thanks.

---

You can also define black as what pure black really is - void of everything - 
no light - nothing. Things we don't see.
And white being light. Things we see.

It does not necessarily need to have a connection with good and bad. You can 
also blacklist legitimate things, but you just don't want to process them right 
now.
The issue is rather that we are talking about "good" and "bad" inputs and then 
connect that to a white- or blacklist. (Because usually the things we do not 
want to see are bad things)

There however is no innate connection from something being black to it being 
bad, rather a coincidence via a couple hops. And only applying in most cases.
For example: "I want to whitelist undesired inputs for logging."

While I see that there is a case for a more unambiguous wording like 
opcache_file_exclude, this matter shall not be about the good-ness or bad-ness 
of the color black.

P.s. And to be honest, I've never heard from a dark-skinned person that they 
felt actually oppressed by words like blacklist.

And here my personal opinion, to be taken with a grain of salt: This whole 
white- and blacklist discussion is mostly "hey I want to make black people feel 
more welcome, let me call blacklist bad and condemn everyone not agreeing. Then 
I have done my good deed" - without having any actual impact on the well-being 
of dark-skinned people. - That's what it feels like for me, but I'm open to 
being corrected by those who are actually dark-skinned and impacted by it, in 
which case I'll immediately retract my last sentence.

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

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

[Bob Weinand]

> Am 17.06.2020 um 01:10 schrieb Benas IML :
> 
> Hey internals,
> 
> This is a completely refined, follow-up RFC to my original RFC. Based on the
> feedback I have received, this PR implements full validation and implicitly
> enforces `void` rules on constructors/destructors while also allowing to
> declare an **optional** explicit `void` return type. Note, that there is a
> small but justifiable BC break (as stated by the RFC).
> 
> RFC: https://wiki.php.net/rfc/make_ctor_ret_void
> 
> Best regards,
> Benas Seliuginas

Hey Benas,

I do not see any particular benefit from that RFC.

Regarding what the manual states - the manual is wrong there and thus should be 
fixed in the manual. This is not an argument for changing engine behaviour.

Sometimes a constructor (esp. of a parent class) or destructor may be called 
manually. Sometimes you have valid information to pass from the parent class.
With your RFC an arbitrary restriction is introduced necessitating an extra 
method instead.

In general that RFC feels like "uh, __construct and __destruct are mostly void, 
so let's enforce it … because we can"?

On these grounds and it being an additional (albeit mostly small) unnecessary 
BC break, I'm not in favor of that RFC.

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

Re: [PHP-DEV] Re: [RFC] Named arguments

[Bob Weinand]

> Am 29.05.2020 um 21:02 schrieb Larry Garfield :
> 
> On Fri, May 29, 2020, at 9:32 AM, Nikita Popov wrote:
>> On Tue, May 5, 2020 at 3:51 PM Nikita Popov  wrote:
>> 
>>> Hi internals,
>>> 
>>> I've recently started a thread on resurrecting the named arguments
>>> proposal (https://externals.io/message/109549), as this has come up
>>> tangentially in some recent discussions around attributes and around object
>>> ergonomics.
>>> 
>>> I've now updated the old proposal on this topic, and moved it back under
>>> discussion: https://wiki.php.net/rfc/named_params
>>> 
>>> Relative to the last time I've proposed this around PHP 5.6 times, I think
>>> we're technically in a much better spot now when it comes to the support
>>> for internal functions, thanks to the stubs work.
>>> 
>>> I think the recent acceptance of the attributes proposal also makes this a
>>> good time to bring it up again, as phpdoc annotations have historically had
>>> support for named arguments, and this will make migration to the
>>> language-provided attributes smoother.
>>> 
>> 
>> Regarding the question of what to do with regard to LSP validation and
>> parameter names changing during inheritance: During internal discussion,
>> the following option has come up as a possible compromise:
>> 
>> 1. When calling a method, also allow using parameter names from the parent
>> class/interface.
>> 2. During inheritance, enforce that the same parameter name is not used at
>> different positions.
>> 
>> This ensures that renaming parameter names during inheritance does not
>> break code relying on parameter names of the parent method. At the same
>> time, it prohibits genuine LSP violations, where a parameter has been moved
>> to a different position.
>> 
>> I've run some static analysis to detect cases that would be affected by the
>> latter check, with these results:
>> https://gist.github.com/nikic/6cc9891381a83b8dca5ebdaef1068f4d The first
>> signature is the child method, and the second the parent method. I did not
>> put in the effort to make this completely precise, so there's both false
>> positives and false negatives here. But it should be enough for a general
>> impression. And the general impression is that these are indeed legitimate
>> LSP violations.
>> 
>> This approach would be an alternative to either silently ignoring the issue
>> (as the RFC proposed), or to warning for all parameter renames.
>> 
>> Regards,
>> Nikita
> 
> Just to make sure I follow what you're proposing, given:
> 
> class P {
>  public function foo($a, $b, $c) { ... }
> }
> 
> This is legal:
> 
> class A extends P {
>  public function foo($a2, $b, $c) {}
> }
> 
> // Mean the same thing:
> $a = (new A)->foo(a = 1, b = 2, c = 3);
> $a = (new A)->foo(a2 = 1, b = 2, c = 3);
> 
> This will parse error:
> 
> class A extends P {
>  public function foo($b, $a, $c) {}
> }
> 
> Am I following the intent correctly?
> 
> If so, that sounds like a very reasonable and safe middle-ground.
> 
> --Larry Garfield

Yes,

that's pretty much the intent - having a very small BC break surface, while 
still allowing for safe usage of named parameters according to both the child 
and parent interface.

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

Re: [PHP-DEV] [RFC] Amendments to Attributes

[Bob Weinand]

> Am 22.05.2020 um 13:08 schrieb Nikita Popov :
> 
> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei 
> wrote:
> 
>> 2. Rename PhpAttribute to Attribute in global namespace (independent of the
>> namespace RFC)
> 
> As was mentioned in one of the previous discussions, we expect that PHP is
> going to ship more language-provided attributes in the future. With this
> proposal we have the "Attribute" attribute, but I expect we'll at least
> have "Deprecated" as well, and probably also something along the lines of
> "Jit" or "NoJit". While I'm happy with "Attribute" living in the global
> namespace, I don't really think we'd want to introduce "Jit" as a class in
> the global namespace. The name is simply to generic and does not indicate
> that this is part of the attribute system. We'd be forced to go with things
> like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to
> me, as we're just reinventing namespaces to avoid using them...
> 
> As such, I would suggest to introduce a common namespace for all attributes
> provided by PHP. This means we'd have Attributes\Attribute,
> Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay
> with the PHP\Attributes\Deprecated variant, but that's a separate question).
> 
> Nikita

At that point, don't we just want to be able to generically mark all attribute 
classes visible as being an Attribute?

Also the classical examples like <> do not tell you anyhow 
that they're Attributes, if the class is accessed outside of attribute context. 
And I guess, with the logic you proposed, it will likely be named 
"ORM\Attribute\Entity" making it even longer.

I think it would be good to be able to later on just write <>, 
<> etc. without further imports, as they seem to be quite basic 
functionality. I think it should remain possible to write simple code without 
much namespace awareness.

Perhaps we should actually name attribute classes including their << and >>. 
Thus "class <> {}" (attribute decl), "new <>()" (custom 
instantiation), "$attribute instanceof <>". (and, for a namespaced 
attribute "$attribute instanceof MyNamespace\<>")
The engine could quite easily support that, it's just a little parser work.

That way the whole discussion as to where to put attributes in the namespace 
hierarchy would be quite moot, for PHP itself as well as userland.

Bob

P.s.: As a caveat, on parameter types, if we expect a value being of an 
attribute class, we'd need to require a qualified name containing at least one 
backslash or import-alias there. But that's acceptable I think, it will just 
happen within some internal attribute processing code.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: Making all Traversables an Iterator or IteratorAggregate

[Bob Weinand]

Hey Sara,

> Am 12.05.2020 um 14:49 schrieb Sara Golemon :
> 
> On Tue, May 12, 2020 at 3:26 AM Nikita Popov  wrote:
>> // WeakMap::getIterator(): Iterator
>> ZEND_METHOD(WeakMap, getIterator)
>> {
>>if (zend_parse_parameters_none() == FAILURE) {
>>return;
>>}
>>zend_create_internal_iterator_zval(return_value, ZEND_THIS);
>> }
>> 
> Given that the body of this method seems to usually (always?) be the same,
> why not define it in InternalIterator and allow it to be inherited?

Good idea.

>> There's some bikeshed potential here regarding the class name.
>> 
> Not personally over-picky, but I do agree that "Internal*" is a bit
> awkward.  Unfortunately there's not much that's better and appropriate for
> exposing to scripts.  This might be one of those rare occasions where
> exposing "Zend" into userspace makes sense.  "PHP" is overloaded into
> several meanings that are significant for userspace developers, but
> something like "ZendIterator" might convey the right level of "This has to
> do with the engine, please move along".  Or maybe go verbose:
> 'IteratorForExtensionClassImplementations'. :p

We call the engine Zend, but eih, that's a rather internal detail we mostly 
don't leak into userland, and I wouldn't do it here either.
InternalIterator is the better choice I think.

>> ZEND_ASSERT(scope->get_iterator != zend_user_it_get_new_iterator); >
> Does this mean that if I do `class Foo implements InternalIterator {}` in a
> script, I can assert (crash) PHP? I don't see anything obvious (at a
> glance) preventing me from inheriting from InternalIterator.

The class is marked final, so userland won't be able to directly extend it. 
(zend_ce_internal_iterator->ce_flags |= ZEND_ACC_FINAL;)

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

Re: [PHP-DEV] [RFC] Keep type of reference params

[Bob Weinand]

> Am 04.05.2020 um 10:53 schrieb Manuel Canga :
> 
> Hi internals,
> 
> 
> 
> I would like to present a possible new RFC( "keep type of reference params" ) 
> for your
> 
> consideration.
> 
> 
> 
> Firstly, an example:
> 
> 
> 
> ```
> 
>  
> 
> 
> function my_array_shift( array & $array ) {
> 
> $array = "string";
> 
> }
> 
> 
> 
> $array = [ 0, 1, 2, 3, 4 ];
> 
> 
> 
> my_array_shift($array);
> 
> 
> 
> count( $array );
> 
> ```
> 
> 
> 
> The result of this code is a warning( in count line ) because of $array is a 
> string. 
> 
> However, I think it should be an error or exception when a string is assigned 
> to $array var. 
> 
> In my opinion, $array var would have to keep its type when function ends.
> 
> 
> 
> What is your opinion ? Do you see it useful ?
> 
> Thanks and I'm sorry for my English( I'm a Spanish ).
> 
> Regards
> 
> --
> 
> Manuel Canga

Hey Manuel,

the primary issue (apart from the BC break) here is leaking the reference 
across the function boundary.

function a(array &$a) {
$GLOBALS["globalA"] = &$a;
}

funcition b() {
$GLOBALS["globalA"] = 10;
}

$a = 1;
a($a);
b();
// $a is magically changed to 10

Yes, you can here verify, that $a is an array at the function boundaries, but 
you cannot afterwards.

If we had proper inout parameters (which do not leak a reference, but assign 
the value of the variable (in callee scope) back to the passed variable from 
caller), then we could easily enforce it.

But as it stands now, this is not an option. (Especially due to the false 
promise this seems to make.)

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

Re: [PHP-DEV] [VOTE] match expression

[Bob Weinand]

> Am 28.04.2020 um 12:48 schrieb Rowan Tommins :
> 
> On Tue, 28 Apr 2020 at 11:19, Ilija Tovilo  wrote:
> 
>>> for the control-flow statement, it feels awkward and not in
>>> keeping with the rest of the language. If they were separate proposals,
>> the
>>> statement would probably end up looking very different.
>> 
>> Can you elaborate? If I made a proposal exclusively for match
>> statements the syntax would be exactly equivalent.
>> 
> 
> 
> If we take away the expression part, the proposal would be to replace this
> switch statement:
> 
> switch ( $expr ) {
> case 1:
> case 2:
>   statement;
> break;
> default:
>   statement;
> break;
> }
> 
> With this match statement:
> 
> match ( $expr ) {
> 1, 2 => {
>   statement;
> },
> default => {
>   statement;
> },
> }
> 
> The extra set of {} inside looks a little odd, but is a reasonable way to
> remove the implicit fallthrough. However, the other changes seem to just be
> arbitrarily new syntax:
> 
> * No "case" keyword
> * => instead of :
> * commas between statement blocks
> 
> If the motivation is simply to fix the current switch statement, why not
> keep the syntax more familiar?
> 
> match ( $expr ) {
> case 1, 2: {
>   statement;
> }
> default: {
>   statement;
> }
> }
> 
> The colon looks unnecessary next to the opening brace, but if we keep it,
> the braces could be optional like they are in an if statement:
> 
> match ( $expr ) {
> case 1, 2: statement;
> default: statement;
> }
> 
> Note that this wouldn't suffer the problems of accidentally running code
> that you get with one-line if statements, because the following could
> simply be a syntax error:
> 
> match ( $expr ) {
> case 1, 2: statement; anotherStatement;
> default: statement;
> }
> 
> 
> That syntax doesn't lend itself as well to being used as an expression, but
> I'm not convinced making one syntax work for both use cases is the right
> goal given the compromises it requires.
> 
> 
> Regards,
> -- 
> Rowan Tommins
> [IMSoP]

Hey Rowan,

I think you should first think about why the "case" needs to exists at all. In 
particular it exists to distinguish goto labels from the case expressions in 
switch. With match, match restricting statements (and thus goto labels) into { 
brackets }, it now is not necessary to do such a distinction and we can get rid 
of the extra token.
"=>" is logical as well, we use the return value of the expressions (see fn() 
and array syntax), the colon is exclusively used for pure statement boundaries.
The comma is necessary for the expression syntax at least (consider match($a) { 
1 => 2  + 2 + 2 => 3 } - is this now match($a) { 1 => 2, (2 + 2) => 3 } or 
match ($a) { 1 => (2 + 2), +2 => 3 } ?) You may argue to make it optional 
behind a statement block though.

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

Re: [PHP-DEV] [VOTE] match expression

[Bob Weinand]

> Am 25.04.2020 um 12:39 schrieb Ilija Tovilo :
> 
> Hi internals
> 
> I have opened the voting on the match expression RFC. It will end on
> 9th of May, 2020.
> https://wiki.php.net/rfc/match_expression
> 
> Here are the last changes:
> 
> In the last update I mentioned allowing return values in blocks.
> Unfortunately, we discovered some technical difficulties (memory
> leaks) which are very hard to solve. Nikita is experimenting on a
> possible solution. There was also a fair bit of backlash over the
> syntax. Thus I have decided to move block expressions to a separate
> RFC. Note that blocks with just statements remain part of this RFC.
> 
> The "duplicate condition" warning mentioned by Dan was removed due to
> the arguments made by Tyson.
> 
> I have also moved the optional semicolon for the match in statement
> form to a separate vote as this was another controversial part of the
> proposal.
> 
> Furthermore I have added another secondary vote for allowing to drop
> (true) conditions as that was suggested multiple times:
> 
> match {
>$age >= 30 => {},
>$age >= 20 => {},
>$age >= 10 => {},
>default => {},
> }
> 
> // Equivalent to
> 
> match (true) {
>$age >= 30 => {},
>$age >= 20 => {},
>$age >= 10 => {},
>default => {},
> }
> 
> There is a separate poll for specifying the reason for a "no" vote.
> Let me know if there are any other reasons so I can add those to the
> poll.
> 
> A personal thank you goes out to Tyson for his guidance!
> 
> Regards,
> Ilija

Hey Ilija,

while in general I'm okay-ish with match using a strict comparison,

shall the "match { $cond1 => {}, $cond2 => {} }" syntax be strict or not? I 
would do a simple truthiness check in that particular case (which IMHO is also 
consistent as there is no explicit value it's compared against).
That way it would essentially have the semantics of a chained ternary without 
being illegible.

At least as match {} without explicit expected value is effectively a boolean 
comparison (doesn't feel really like a strict value comparison), it should also 
behave like a classical boolean comparison.

In general, apart from that very last change (I think you should have given it 
at least 1-2 days of consideration before starting the vote), the RFC is nice 
and provides a concise syntax for something which usually is quite uglily 
expressed.

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

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

[Bob Weinand]

Actually,

I forgot that for proper generics implementations, collections etc. will 
obviously need to specify "allowing any type". As such the introduction of 
mixed is pretty much necessary.

As in class Foo { … } $foo = new Foo;

As such, I'm actually in favor of introducing it.

Bob

> Am 24.04.2020 um 14:11 schrieb Bob Weinand :
> 
> Hey Dan,
> 
> this, I consider one of the few concepts which should never make it into PHP.
> 
> In particular, the main problem with mixed is that it is a very easy "I have 
> no idea how to type that properly, so just let's use mixed".
> 
> And really, in general, except for some debug functions, mixed is just an 
> excuse to not use proper generics. I cannot think of non-debug scenarios 
> where we are juggling truly unknown types where the type is unidirectional.
> (Uni-directional means: there is no corresponding getting/forwarding function 
> for an input.)
> 
> Mixed is in almost every case just patching the holes in PHPs type system. 
> And as such, I'd rather promote RFCs trying to properly fix the gaps in the 
> type system than supporting mixed.
> 
> Mixed is a hack, do not use mixed.
> 
> Bob
> 
> P.s.: If you want to migrate your types and have an overview of what's 
> already migrated, maybe just add a comment // type-migrated before or 
> similar? But that's seriously not the business of the language.
> 
>> Am 20.04.2020 um 13:17 schrieb Dan Ackroyd :
>> 
>> Hi Internals,
>> 
>> Here is an RFC for adding a 'mixed' type to the language:
>> https://wiki.php.net/rfc/mixed_type_v2
>> The RFC builds on an earlier draft by Michael Moravec.
>> 
>> Part of the motivation for pursuing this RFC was my recent experience
>> in upgrading an application to PHP 7.4.
>> 
>> Being able to add types to the application made the code much easier
>> to reason about, but there were places where I couldn't add type info
>> due to the lack of mixed. That made it hard to see if that piece of
>> code had been upgraded (but type info couldn't be added), or if that
>> code still needed to be upgraded.
>> 
>> cheers
>> Dan
>> Ack
>> 
>> -- 
>> 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
> 

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

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

[Bob Weinand]

Hey Dan,

this, I consider one of the few concepts which should never make it into PHP.

In particular, the main problem with mixed is that it is a very easy "I have no 
idea how to type that properly, so just let's use mixed".

And really, in general, except for some debug functions, mixed is just an 
excuse to not use proper generics. I cannot think of non-debug scenarios where 
we are juggling truly unknown types where the type is unidirectional.
(Uni-directional means: there is no corresponding getting/forwarding function 
for an input.)

Mixed is in almost every case just patching the holes in PHPs type system. And 
as such, I'd rather promote RFCs trying to properly fix the gaps in the type 
system than supporting mixed.

Mixed is a hack, do not use mixed.

Bob

P.s.: If you want to migrate your types and have an overview of what's already 
migrated, maybe just add a comment // type-migrated before or similar? But 
that's seriously not the business of the language.

> Am 20.04.2020 um 13:17 schrieb Dan Ackroyd :
> 
> Hi Internals,
> 
> Here is an RFC for adding a 'mixed' type to the language:
> https://wiki.php.net/rfc/mixed_type_v2
> The RFC builds on an earlier draft by Michael Moravec.
> 
> Part of the motivation for pursuing this RFC was my recent experience
> in upgrading an application to PHP 7.4.
> 
> Being able to add types to the application made the code much easier
> to reason about, but there were places where I couldn't add type info
> due to the lack of mixed. That made it hard to see if that piece of
> code had been upgraded (but type info couldn't be added), or if that
> code still needed to be upgraded.
> 
> cheers
> Dan
> Ack
> 
> -- 
> 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] Warn when declaring required parameter after optional one

[Bob Weinand]

Hey,

While I generally agree that it likely is a bug in new code, I would rather 
deprecate it than warn or even error: the change would make it impossible to 
retain a type without warning while preserving compatibility with an old PHP 
version and making incremental migrations harder (would then not be possible to 
write warning-free code running on 7.0 and 8.0 at the same time while retaining 
type information).

I would like to see it deprecated and then removed in 4+ years.

Bob

> Am 09.01.2020 um 13:27 schrieb Nikita Popov :
> 
> Hi internals,
> 
> I've created https://github.com/php/php-src/pull/5067 to make code like
> 
>function test($foo = null, $bar) {}
> 
> throw a warning:
> 
>Warning: Required parameter $bar follows optional parameter
> 
> Historically, having an "optional" parameter before a required one was
> useful for poor man's nullable types. That is, one could write
> 
>function test(FooBar $param = null, $param2)
> 
> to get an effective
> 
>function test(?FooBar $param, $param2)
> 
> signature on old PHP versions that did not have native support for nullable
> types.
> 
> Since nullable types have been available since PHP 7.1, having a required
> parameter after an optional one is increasingly likely a bug rather than an
> intentional workaround, so I think it would be good to throw a warning for
> this case.
> 
> What do you think?
> 
> Nikita

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

Re: [PHP-DEV] Inline switch as alternative to nested inline conditional

[Bob Weinand]

Am 16.10.2019 um 21:19 schrieb Claude Pache 
mailto:claude.pa...@gmail.com>>:

Le 16 oct. 2019 à 19:11, Bob Weinand 
mailto:bobw...@hotmail.com>> a écrit :

Am 16.10.2019 um 03:46 schrieb David Rodrigues 
mailto:david.pro...@gmail.com>>:

Hello. I like to suggests a discussion about a FR to make possible to
inline switch, as an alternative to nested inline conditionals.

$value = switch (expr()) {
 case A1: return A2;
 case B1: return B2;
 default: return C;
}

Instead of:

$expr = expr();
$value = $expr == A1 ? A2 : ( $expr == B1 ? B2 : C );

Just a discussion to check what do you think.

--
David Rodrigues

Hey David,

what's the concrete advantage of this syntax as opposed to the already possible:

$value = [
  A1 => A2,
  B1 => B2,
][expr()] ?? C;

there are only differences in edge cases (with floats or with type mixing) … 
but for the vast majority of use cases, it is just as powerful as what you 
proposed.

Bob

One concrete advantage is, when A2 or B2 are complex expressions that are 
costly to evaluate or that throw error when given inappropriate input, they are 
not evaluated needlessly.

—Claude

Most switch values aren't expensive though.
There's always a possibility to prefix with fn() =>:

$value = ([
  A1 => fn() => A2,
  B1 => fn() => B2,
][expr()] ?? fn() => C)();

For the normal case, this is unneeded though (as in, most of my use cases for 
"inline switches" are typically with string operations). Your mileage may vary.

Bob

Re: [PHP-DEV] Inline switch as alternative to nested inline conditional

[Bob Weinand]

> Am 16.10.2019 um 03:46 schrieb David Rodrigues :
> 
> Hello. I like to suggests a discussion about a FR to make possible to
> inline switch, as an alternative to nested inline conditionals.
> 
> $value = switch (expr()) {
>case A1: return A2;
>case B1: return B2;
>default: return C;
> }
> 
> Instead of:
> 
> $expr = expr();
> $value = $expr == A1 ? A2 : ( $expr == B1 ? B2 : C );
> 
> Just a discussion to check what do you think.
> 
> -- 
> David Rodrigues

Hey David,

what's the concrete advantage of this syntax as opposed to the already possible:

$value = [
A1 => A2,
B1 => B2,
][expr()] ?? C;

there are only differences in edge cases (with floats or with type mixing) … 
but for the vast majority of use cases, it is just as powerful as what you 
proposed.

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

Re: [PHP-DEV] Re: Bringing Peace to the Galaxy

[Bob Weinand]

Hey Zeev,

> Am 09.08.2019 um 19:44 schrieb Zeev Suraski :
> 
> On Fri, Aug 9, 2019 at 7:44 PM Dan Ackroyd  wrote:
> 
>> On Fri, 9 Aug 2019 at 17:10, Zeev Suraski  wrote:
>>> 
>>> we’re discussing whether it makes sense to introduce a sister language
>> to PHP.
>> 
>> Zeev also wrote:
>>> It will take no additional resources,
>> 
>> First, those two statements are mutually exclusive.
>> 
> 
> Before I move on, I have to say I admire your level of confidence.  I can
> only dream of having something even remotely close.
> 
> You're talking to a person that co-wrote the PHP engine, twice, that led
> parts of a 3rd engine rewrite, that helped lead (although at a hands-off
> manner) a 4th engine rewrite, that wrote OPcache, and a bunch of other
> things - and yet you still feel confident to tell me that I have no idea
> what I'm talking - when talking about precisely that.

It's clearly quite a feat, your contributions to PHP 3 and PHP 4.
This does not give you any authority now. You are not a current active code 
maintainer.
I won't deny you the respect for your former achievements - but as it is now, 
you are - not to sound harsh, but just stating the fact - a single person here 
with opinions (like we all).

From my perspective at least (and others I've talked to), you are writing like 
you would have a leadership position which you do not have.

I honestly think you should back off for some time. I definitely appreciate 
everyone sharing their opinions ... More on that below.

Back to the main question:
I think I have worked much more recently than you actively on this project and 
I can tell you that Dan is absolutely right here.

> If I were in your place, I'd be wondering "am I missing something?" and
> probably try to ask some clarifying questions before telling that other guy
> that he's clueless and/or lying.  Even if I disagreed with that person on
> virtually everything.

I cannot tell - I have no way to analyze your brain - it seems though, you are 
thinking to know more than you actually do.
Maybe it's wrong, maybe it's right. Dan is not necessarily trying to be 
disrespectful here, he just simply does not add the disclaimer "it seems to 
me". It is his perspective he is sharing, and I must say it overlaps with mine.

> With that out of the way - the very short version is that there's nothing
> mutually exclusive about these statements.  In fact, saying that means that
> you really do not understand what the idea is.  There could be several
> reasons for that - but I'm willing to take the blame as perhaps I didn't
> make it entirely clear.  I'll try to remedy that separately from this email.
> 
> Second, the idea of keeping PHP as it currently is, and pushing people
>> who want to evolve the language out from core PHP to make their own
>> language, is effectively telling those people to make a fork of the
>> project.
>> 
> 
> This is another illustration, an even clearer one - that you simply don't
> understand what the idea is at any meaningful level.  Here too - I'll take
> the blame.  I'm going to try and fix that.
> 
> This is not an appropriate thing to suggest.

At the very least there's an additional maintenance burden (let alone 
implementing everything we'd like to change).

>> Please stop trying to regain control of the PHP project either through
>> direct threats or through telling people that they should fork off the
>> project if they want to evolve PHP.
>> 
>> I strongly feel the conversations you are provoking on internals are
>> not productive or healthy for the project.
>> 
> 
> Dan, don't get this the wrong way, but if anybody is behaving
> inappropriately, that would be you.  You repeatedly talk to me in a
> condescending (text) tone, you're virtually always interpreting my words in
> the most negative and malicious way possible (and beyond), and you don't
> shy away from doing that publicly.  You're being repeatedly disrespectful.
> 
> Adding
> 
>> cheers
> 
> at the end does not change that..
> 
> I don't address you in such a disrespectful manner, neither should you.
> Please stop.

I'm not going to defend Dan's tone here, but let me agree with what he's saying.
You are being divisive, intentionally or not (I assume the latter), whether 
you're aware or not.

Let me, at this place, kindly ask you to not repeatedly engage in a same 
discussion. Have your voice heard, once.
There are a lot of topics where you state something (with content going also 
towards other tangents, discussing voting systems) and then the topic starts 
going off a tangent.
This is annoying. I want to read the technical points. And then form my 
opinion. Not find long discussions about anything else or backs and forths not 
leading to any result or providing more technical context.

Get a chat room to discuss process issues. Don't always be the one who presents 
the ideas. You ARE being viewed as controversial. You bringing proposals up is 
not going to be a productive discussion.
Let others be your 

Re: [PHP-DEV] [RFC] Explicit call-site send-by-ref syntax

[Bob Weinand]

> Am 30.07.2019 um 17:14 schrieb Zeev Suraski :
> 
> On Tue, Jul 30, 2019 at 6:10 PM Levi Morrison 
> wrote:
> 
>> On Mon, Jul 29, 2019, 10:55 PM Zeev Suraski  wrote:
>> 
>> 
> I think ignoring people is totally acceptable behaviour on this list. May I
>> remind you that in the not distant past this list was called a toxic
>> kindergarten and other similar names by former and current contributors?
>> Simce we have little policy on ejecting toxic contributors, ignoring people
>> is the only way to keep sanity.
> 
> 
> It is not acceptable, period.  If we need to pull rank with group@ here,
> we will.
> 
> Zeev

You can either silently ignore somebody or announce it. You may consider it a 
courtesy to have it announced so that they don't wonder why they are not being 
replied to.
For me it's perfectly fine. Sure I wouldn't be happy if anyone said that about 
me, but I would have to accept it.
Everyone is free on his own who to listen to and who to ignore. 

It's not up to you alone whether it's acceptable. Maybe it isn't for you. 
You're free to say that. But it's definitely not up to you to threaten, as an 
individual, with "group@". You are not a "we".

I'd appreciate if, now and in future, you would respect everyones free will in 
that regard;
thanks,
Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Vote] Change the precedence of the concatenation operator

[Bob Weinand]

> Am 01.05.2019 um 00:41 schrieb Bob Weinand :
> 
> Hey,
> As announced yesterday, I'm now starting the vote on this RFC.
> 
> I'm confident that the impact is really that minimal that a relatively quick 
> deprecation and change path is preferred.
> 
> https://wiki.php.net/rfc/concatenation_precedence
> 
> The vote ends on May 15.
> 
> Thanks,
> Bob

Hey,

I just merged the patch as the RFC has been accepted; the primary vote closing 
with 31 in favor and 4 against.
The secondary vote about the deprecation in PHP 7.4 has been accepted as well, 
with 30 in favor and 7 against.

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

Re: [PHP-DEV] [RFC] Change the precedence of the concatenation operator

[Bob Weinand]

Am 25.04.2019 um 11:52 schrieb Nikita Popov 
mailto:nikita@gmail.com>>:

On Thu, Mar 28, 2019 at 2:33 PM Bob Weinand 
mailto:bobw...@hotmail.com>> wrote:
Hey,

I feel like concatenation having the same precedence than addition and 
subtraction is promoting programmers to make mistakes. Albeit typically easy to 
catch ones, it is a quality of life change at least.

Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedence

Bob

Similarly to the ternary associativity RFC, I've analyzed the top 2000 composer 
packages and checked whether they would be affected by this change: 
https://gist.github.com/nikic/a4df3e8e18c7955c2c21cf6cdb4cbfaa

The tl;dr is that there were 5 instances where behavior would change per this 
RFC, and all 5 of them are bugs in current code and would be interpreted 
correctly after this RFC.

Nikita

Thanks for the analysis,

Given the confirmation that the impact is minimal (rather beneficial), I'll add 
this to the RFC and start voting tomorrow.

Bob

[PHP-DEV] [RFC] Change the precedence of the concatenation operator

[Bob Weinand]

Hey,

I feel like concatenation having the same precedence than addition and 
subtraction is promoting programmers to make mistakes. Albeit typically easy to 
catch ones, it is a quality of life change at least.

Hence I'm proposing a RFC changing the precedences:
https://wiki.php.net/rfc/concatenation_precedence

Bob

Re: [PHP-DEV] RFC Draft: Comprehensions

[Bob Weinand]

> Am 10.03.2019 um 22:44 schrieb Larry Garfield :
> 
> Hello, peoples.  I know it's been discussed once or twice before on the list, 
> many years ago, but not recently.  I therefore feel OK putting forth the 
> following draft proposal for Comprehensions, aka "compact generators", in PHP:
> 
> https://wiki.php.net/rfc/comprehensions
> 
> Sara Golemon has written a preliminary patch that is partially complete (see 
> the RFC link for details, it's impressively simple), but unfortunately 
> doesn't have the bandwidth to complete it at this time.  I am therefore 
> looking for collaborators with more knowledge of internals than I (which is 
> almost everyone) to help finish it up.
> 
> The syntax proposed is also subject to revision if a terser but still 
> lexer-friendly alternative can be proposed.
> 
> At the moment I'm not calling this Proposed yet, as I don't feel comfortable 
> doing so until someone else is on board to finish coding it.  That said, if 
> someone wants to weigh in on the concept for now (hopefully supportively) 
> that's also fine.
> 
> Anyone excited enough to help finish the job?
> 
> (This is my first RFC collaboration, so if you're going to smack me for 
> goofing something please be gentle about it.)
> 
> -- 
>  Larry Garfield
>  la...@garfieldtech.com

Hey Larry,
First, I like it. (the idea/intention behind of providing a compact way for 
list comprehensions)

Though in general, I think this would be better off implemented with a more 
flexible short closure; it feels like a special case of these. I.e. that the 
comprehension syntax can be simply desugared to an immediately invoked short 
closure. At that point also, it can be a compiler only patch, if we have short 
closures with the appropriate binding behavior.
I guess it should be pretty easy to build that on top of my existing short 
closures patch.

Regarding the syntax, I'd not conflate for with foreach, the distinction is 
built into PHP and as such should remain.
We also might have trivial argument-less short closures written as "{ stmt }" 
simply, having the comprehension written as $gen = {foreach($list as $x) if($x 
% 2) yield $x * 2;}(); (note the trailing "()" function call - if we desire to, 
we might make the semicolon at the end of that single-statement closure 
optional.)

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

Re: [PHP-DEV] Alternative voting reform: Streamlining the RFC process

[Bob Weinand]

> Am 03.02.2019 um 06:18 schrieb Zeev Suraski :
> 
>> -Original Message-
>> From: Nikita Popov 
>> Sent: Saturday, February 2, 2019 6:24 PM
>> To: PHP internals 
>> Subject: [PHP-DEV] Alternative voting reform: Streamlining the RFC process
>> 
>> Hi internals,
>> 
>> After discussing the topic with a number of current and former contributors, 
>> I
>> feel that the workflow & voting RFC currently under discussion is moving us 
>> in
>> the wrong direction. I will not comment on the rather questionable proposed
>> changes to voting eligibility, as these are already extensively discussed in 
>> the
>> RFC thread.
> 
> Personally, I find any proposal that does not deal with clearly defining 
> voting eligibility not only questionable, but a non-starter, that has no 
> parallels in any other major Open Source projects.
> 
> The suggestion that the new RFC makes life more difficult, compared to the 
> current Voting RFC, is simply wrong.  It is, in fact, very much the same - 
> except it's a lot more well defined in terms of 'what happens if' - which in 
> the years since the 2011 Voting RFC was enacted became a de-facto wild-west.
> 
> It may initially feel warm & fuzzy to  have vague, fluid rules that are 
> remarkably open to interpretation.  But it's not a good idea at all.
> 
> Zeev

Hey Zeev,

why is dealing with voting eligibility a requirement for a new RFC dealing with 
the RFC process? Everything which is not dealt with, is simply inherited from 
status quo. And I personally don't think the current rules regarding voting 
eligibility, while possibly not perfect, are in such a bad state that they 
immediately need a rework. The door to concrete, separate proposals fixing 
voting eligibility is not closed with this RFC. You are always free to open a 
new specific RFC and discuss about a voting eligibility proposal.

In addition, the newly proposed RFC here is absolutely not vague. It is pretty 
well defined, showing a few clear boundaries. For everything else it is the 
task of the voter to establish whether a RFC is ready and shall be voted in as 
is. It's precisely that which makes a great voting process. In particular with 
a 2/3 required majority, I strongly doubt that bullshit RFCs which are quickly 
proposed and moved to vote, will ever be accepted. I trust our voters enough to 
know when something should definitely not be accepted.

And I strongly hope that you are not lacking faith in us PHP RFC voters, that 
you feel like you couldn't trust us to apply sensible judgement to each RFC.

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

[PHP-DEV] [RFC] [VOTE] Typed properties v2

[Bob Weinand]

Hey,

As announced, we are starting the vote on typed properties today.

The voting period is two weeks, until sometime in the evening on Tuesday 
25-09-2018.

Please find the RFC at https://wiki.php.net/rfc/typed_properties_v2.

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

Re: [PHP-DEV] [RFC] Pre-Vote: Typed properties

[Bob Weinand]

Am 08.09.2018 um 09:51 schrieb Marco Pivetta 
mailto:ocram...@gmail.com>>:

Hey Bob,

Did the implementation change a lot since it was last successfully tested, or 
is it mostly stabilization changes?

Greets,

Marco

On Fri, 7 Sep 2018, 23:19 Bob Weinand, 
mailto:bobw...@hotmail.com>> wrote:
Hey,

Due to the mailing list downtime this has been delayed a bit ...

I'd like to push the Typed properties RFC forward to a vote soon: 
https://wiki.php.net/rfc/typed_properties_v2

Unless there are major objections, I will start the vote on Tuesday for two 
weeks.

Bob

Hey Marco,

no it didn't, just a few bugfixes and the occasional merge from master.

Bob

[PHP-DEV] [RFC] Pre-Vote: Typed properties

[Bob Weinand]

Hey,

Due to the mailing list downtime this has been delayed a bit ...

I'd like to push the Typed properties RFC forward to a vote soon: 
https://wiki.php.net/rfc/typed_properties_v2

Unless there are major objections, I will start the vote on Tuesday for two 
weeks.

Bob

RE: [PHP-DEV] [RFC] Typed Properties

[Bob Weinand]

From: nicolas.gre...@gmail.com  On Behalf Of Nicolas 
Grekas
Sent: Thursday, June 21, 2018 18:51
To: Bob Weinand 
Cc: Nikita Popov ; PHP internals 
Subject: Re: [PHP-DEV] [RFC] Typed Properties


something like a ReflectionReference class, which will give you the referencing 
properties via ReflectionProperty instances

I may not have the object when walking on data structures, but only the 
reference (in an array.)
It could work this way I suppose: `ReflectionReference::fromArray(array $array, 
string $key): ?ReflectionReference`,
returning `null` when `$array[$key]` is not a reference, and the instance 
otherwise.
WDYT?

I imagined a ReflectionReference::__construct(&$value), with methods 
getRefcount() : int and getReferencingProperties() : ReflectionProperty[]

To check whether it’s a reference at all, you’d use if ((new 
ReflectionReference($array[$key]))->getRefcount() > 2) { /* is ref */ } else { 
/* not a ref */ }, for computing the allowed types you’d intersect the types of 
the ReflectionProperties returned by getReferencingProperties().

Bob

RE: [PHP-DEV] [RFC] Typed Properties

[Bob Weinand]

> From: Patrick ALLAERT 
> Sent: Thursday, June 21, 2018 18:25
> To: Nikita Popov 
> Cc: PHP internals 
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
>
> My only concern is about regular variables, not bound to any classes. Isn't
> that a little bit inconsistent that classes properties could be typed, but 
> not a
> regular variable in the middle of a function/method/plain "script"
> file?
> 
> I would see some benefit doing something like:
> 
> string $content = file_get_contents("/foo/bar");
> 
> (Sorry if this has been raised already in the past)
> 
> Patrick

Hey Patrick,

It is an option to allow this in future, but for now I consider this too far 
out of scope, possiv and it will, in particular also require greater changes to 
the engine - I guess it would about double the size of the patch again. (and 
this patch is already everything, but small.)

This feature would as well be possibly not uncontroversial, needs thinking 
about the scoping of the variable type (Lifetime until unset()? Lifetime until 
function end? etc.) - I definitely would not go too far with this RFC. The 
topic is typed properties and that's what the scope of the RFC shall also be.

Bob

RE: [PHP-DEV] [RFC] Typed Properties

[Bob Weinand]

Hey Larry,

> From: Larry Garfield 
> Sent: Thursday, June 21, 2018 18:17
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
> Questions along the way:
> 
> * There was at one point in time a related RFC regarding property
accessors
> (dedicated getter/setter methods for each property that get called
> automatically).  That was rejected largely on performance grounds at the
> time.
> Would this RFC 1) Hinder returning to property accessors in the future 2)
Help
> resolve some of the issues there indirectly 3) Have no effect on the
viability
> of accessors?

I don't think it'll hinder them, accessors are pretty orthogonal to this
feature. Sure they'll have to cast the returned value according to the
property type, but that's no different than a return type and just like
__get() works in this RFC. But that's already about the complete impact.
An accessor ultimately isn't really any more expensive than a __get() call
at a fundamental level.

> * How much compile time detection is possible?  Eg, the following code
> would clearly never work:
> 
> class Foo {
>   protected int $val;
> 
>   public function setVal(string $val) : void {
> $this->val = $val;
>   }
> 
>   public function getVal() : string {
> return $this->val;
>   }
> }
> 
> (I suppose technically it might work in coercive mode, but not strict
mode?)
> Would this be a compile time error, or a runtime error when you first try
to
> run it?  (I'm assuming IDE linters would be able to catch it, but if the
engine
> could too that's even better.)

PHP core generally does no type analysis at all at compile-time. Any type
analysis is happening in opcache/Optimizer and until now opache/Optimizer
hasn't chosen to warn if it encounters impossible conditions. This may or
may not change in future, but isn't related here.
So it is a runtime error; any other behavior would be out of scope of this
RFC.

Bob


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

RE: [PHP-DEV] [RFC] Typed Properties

[Bob Weinand]

> From: nicolas.gre...@gmail.com  On Behalf Of
> Nicolas Grekas
> Sent: Thursday, June 21, 2018 16:08
> To: Nikita Popov 
> Cc: PHP internals 
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
> 
> Hi Nikita, Bob,
> 
> I anticipate one case on Symfony VarDumper that will break on typed
> references:
> 
> the only way to detect references is by injecting cookies in arrays, e.g.:
> $a = (array) $someObjectOrArray;
> $cookie = new stdClass();
> $b = $a;
> $b[$k] = $cookie;
> if ($a[$k] === $cookie) {
>   // Here we have a reference
> }
> 
> I'd need to wrap the assignation in a try/catch now:
> try {
> $b[$k] = $cookie;
> } catch (TypeError $e) {
>   // Here we have a typed reference that doesn't accept stdclass }
> 
> So far so good I suppose. I just wanted to raise the point if it matters at 
> all.
> 
> Thank you,
> Nicolas

We haven't implemented that (yet?), but I considered something like a 
ReflectionReference class, which will give you the referencing properties via 
ReflectionProperty instances.
The implementation easily allows for that as it tracks the referencing 
properties for calculating the allowed types.

I didn't consider it essential for the initial implementation in 7.3 and thus 
hadn't written it on the TODO list for that RFC.
But if you think it's important (it has real world needs), then we may consider 
extending the RFC to include that.

Bob

RE: [PHP-DEV] [RFC] Typed Properties

[Bob Weinand]

Hey Sara,

> From: p...@golemon.com  On Behalf Of Sara Golemon
> Sent: Thursday, June 21, 2018 15:43
> To: Nikita Popov 
> Cc: PHP internals 
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
> 
> On Wed, Jun 20, 2018 at 4:59 PM, Nikita Popov 
> wrote:
> > Finally, while this RFC currently targets PHP 7.3, this is a large and
> > complex proposal and we may not be able to meet the deadline, in which
> > case this feature will go into the next PHP version.
> >
> IMO it's already too late for something of this size to realistically make 
> 7.3. If a
> vote comes up targeting 7.3 I intend to vote no purely on procedural
> grounds. A 7.4 target will quite probably see a yes from me, however.
> 
> -Sara

I agree that we're pretty late to the party, however I see typed properties 
being a pretty central feature to the PHP 7.3 feature set then, just because of 
its size.
I think it may be worth pushing the release of 7.3  a few weeks back instead, 
if we decide to have this feature make it into PHP 7.3.

The current feature set of PHP 7.3 is pretty small, and I consider it a good 
idea to see how typed properties play out in 7.3 before we consider other 
typesystem improvements.
Waiting a year more would give us less insight into what people are still 
missing and wishing for.

Thus I don't consider it a very good idea to be too conservative here.

An other option would be though, to include a secondary vote "7.3, 7.3 and a 
little delay or 7.4".

Bob

RE: [PHP-DEV] [RFC] Typed Properties

[Bob Weinand]

> From: Marco Pivetta 
> Sent: Thursday, June 21, 2018 01:10
> To: Nikita Popov 
> Cc: PHP Internals List 
> Subject: Re: [PHP-DEV] [RFC] Typed Properties
> 
> Hi Nikita, Bob,
> 
> On Wed, 20 Jun 2018, 23:59 Nikita Popov,  wrote:
> 
> > Hi internals,
> >
> > Bob and I would like to present a new typed properties proposal for
> > your
> > consideration:
> >
> >
> >
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki
> >
> .php.net%2Frfc%2Ftyped_properties_v2=02%7C01%7C%7Ca414560298
> 8f413
> >
> 3a54808d5d7031564%7C84df9e7fe9f640afb435%7C1%7C0%7C6
> 366513
> >
> 30591392793=M70Asi8WqXbP6icXeVsdsBuI1GiK9UjgHj9EoZHX4%2Bg
> %3D
> > erved=0
> >
> > The proposal allows you to annotate properties with types, which are
> > enforced at runtime. Unlike the previous RFC on this topic, the new
> > proposal also supports typed static properties and references to typed
> > properties.
> >
> > Please note that next to the main body, the RFC also contains an
> > "Alternatives" section, which explores the problem space and considers
> > trade-offs of different behaviors in some detail.
> >
> > Finally, while this RFC currently targets PHP 7.3, this is a large and
> > complex proposal and we may not be able to meet the deadline, in which
> > case this feature will go into the next PHP version.
> >
> > Regards,
> > Nikita
> >
> 
> This is awesome news! I skimmed over the proposal and it is extremely well
> thought out, and almost everything that was causing a -1 on the previous RFC
> is gone: kudos!
> 
> The last bit that is missing is the `__get` kink, mostly because `__get()` is
> "squishy by design". Still, the fact that references are properly typed
> mitigates the issue for my shady use-cases (I've got a reputation there), so
> I'm quite happy with an implicit magic type check. One thing I couldn't find 
> is
> whether this magic check is also enforced when calling `__get()` explicitly,
> and not via the guards in the engine.
> 
> Is the current development branch usable for testing something locally? I
> can't see any obvious mistakes here, but I just wanted to try this out with
> some of the more obscure libraries that touch property state at the level that
> is covered by this RFC.

__get() is a very normal function - the special semantics are generally only 
applied if called for overloaded properties. So obviously, there is no check 
applied if you call it directly.

The dev branch is stable for testing, yes. Would appreciate reports about any 
bugs you find.

Bob

[PHP-DEV] Re: 7.2 behavior break, Bug #74836 isset on zero-prefixed numeric indexes in array broken

[Bob Weinand]

Am 03.07.2017 um 09:03 schrieb Dmitry Stogov 
>:

Hi,

Please take a look at https://bugs.php.net/bug.php?id=74836
What is the best option to fix this?

The most consistent way, from my point of view - disabling zero-prefexed 
numeric strings in all cases, but this is a new behavior break.

Thanks. Dmitry.

Hey,

yep, it's probably best to allow only reversible string->integer conversions 
here.
We also shall then emit an E_NOTICE error, just like on normal arrays.

I see no reason to let invalid indices just silently pass on strings.

Bob

Re: [PHP-DEV][RFC][VOTE] Allow abstract function override

[Bob Weinand]

> Am 28.03.2017 um 06:58 schrieb Marco Pivetta :
> 
> Voted "no" because of this paragraph:
> 
>> This RFC proposes to allow this, even if it has very few uses, and
> because there is no reason to disallow a compatible redefinition.
> 
> I couldn't see a use-case.
> 
> In addition to that, this breaks the assumption that the topmost abstract
> signature is the authoritative one. That is a subtle BC break, but still a
> BC break. Yes, I know I'm annoying, sorry 


Hey,
May you please explain where that's a BC break?
If there was a BC break, the BC break was in PHP 7, where that guarantee was 
broken, as the RFC states in its introduction.
Now the only guarantee is that the all abstract function signatures are the 
same ones. Which is not an useful guarantee by any means.

The only thing this RFC changes is making abstract and normal classes 
consistent, which is a good thing. Less special cases.

Bob

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

[Bob Weinand]

> Am 31.01.2017 um 19:41 schrieb Christoph M. Becker :
> 
> On 31.01.2017 at 19:16, Michael Morris wrote:
> 
>> On Tue, Jan 31, 2017 at 12:29 PM, Larry Garfield 
>> wrote:
>> 
>>> My question is why there's no mention of HHVM short closures, or the
>>> previous RFC to take that approach.  See:
>>> 
>>> https://docs.hhvm.com/hack/lambdas/introduction
>> 
>> For what it's worth I'd rather look at
>> 
>> array_map( $x ==> $x + 1);
>> 
>> than
>> 
>> array_map( fn($x) => $x + 1 )
>> 
>> Not to mention the former isn't a bc break.
> 
> Neither is supposed to work, though. :)
> 
> Anyhow, I'm not sure whether I'd prefer
> 
>  array_map($a, $b, $c ==> $a + $b + $c, $a1, $a2, $a3)
> 
> over
> 
>  array_map(fn($a, $b, $c) => $a + $b + $c, $a1, $a2, $a3)
> 
> or maybe
> 
>  array_map(fn $a, $b, $c => $a + $b + $c, $a1, $a2, $a3)
> 
> Somehow, I tend to like a trailing keyword for better left-to-right
> readability.
> 
> -- 
> Christoph M. Becker

The RFC states that we're needing some form of a prefix in order to avoid 
implementing gigantic lexer hacks.
HHVM internally implements it by parsing some part of the syntax INSIDE the 
lexer and then emitting a token before the first parameter to tell the parser 
where a short Closure begins.
Having a normal terminal symbol easily allows the parser to detect short 
Closures, without any hacks.

It is just not a practical option from a technical point of view, and thus not 
worth even considering.

Bob

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

[Bob Weinand]

> Am 31.01.2017 um 21:45 schrieb Andrea Faulds :
> 
> Hi Marc,
> 
> Marc Bennewitz wrote:
>> - Also I like the "use"  keyword you have to define your variables
>> 
>>-> Would it be helpful to allow "function () use (*) {}" to inline
>> all available variables?
> 
> I did think of that, but it's not as concise as not having to specify `use` 
> at all. You could take the opposite approach and auto-capture by default, but 
> permit `use ()` to capture nothing, alongside regular `use (...)` for 
> explicit capture of variables.
> 
> Thanks.
> 
> -- 
> Andrea Faulds
> https://ajf.me/

Hey Andrea,
you realize that you are actually proposing quite a heavy BC break?

Any code which uses the same variable than in parent scope and does not 
overwrite it before its first usage will break.

E.g.:

$foo = [1,2,3];
// more code working on foo
doSomeAction(function($bar) {
// waaah, $foo is now [1,2,3] instead of null
foreach ($bar as $x) {
$foo[] = $x;
}
return $foo;
});

Or what I have seen in real code:

$response_text = "Do action";
store_response($response_text);
// much later
doSomeAction(function() {
$response_text .= "Do other action"; // Note that accidental .= instead of =
store_response($response_text);
});

The code still works as expected, because things are NULL-initialized currently.
Now with implicit auto-capture this is breaking. No ahead of time errors like 
parse or compile errors, which warn you. Just subtly breaking. Depending on 
where it's done, it may not be even noticed soon (variables with the same name 
at different places tend to have compatible types), just misbehave subtly.

This is not acceptable.

Now, when you suggest "function($bar) use (*) => $foo + $bar", I feel like half 
the point of the RFC, the conciseness of the syntax, is missed.
And I'd also reject function($bar) => $foo + $bar as this would mean the 
"function" keyword introducing different semantics depending on what follows. 
[apart from being still not as concise as "fn"]

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

Re: [PHP-DEV] [RFC][Discuss] Arrow Functions

[Bob Weinand]

Hey,

> Am 31.01.2017 um 11:23 schrieb Michael Wallner :
> 
> On 31/01/17 05:53, Stephen Reay wrote:
>> Hi Andrea, All,
>> 
>>> On 31 Jan 2017, at 08:12, Andrea Faulds  wrote:
>>> 
>>> Is it necessary to introduce a new keyword, fn?
>>> 
>>> I think you'd get a similar benefit from:
>>> 
>>>   function($x) => $arr[$x]
>>> 
>>> Likewise, is it necessary to restrict auto-capture to the =>
>>> syntax? Couldn't we allow the following?
>>> 
>>>   function ($x) {
>>>   return $arr[$x];
>>>   }
>>> 
>> 
>> I agree that the `fn` keyword isn’t really necessary. I’ve never
>> quite understood how arrow functions with implied returns etc are
>> supposed to make for *more* readable code, but if they’re going to be
>> part of the language please at least keep some consistency with
>> regular closures.
> 
> Yes, I also think that keeping the function keyword would be better.
> 
>> 
>> In the case that regular closures got auto-capture, would a
>> `use($foo, $bar, $baz)` segment on a closure still be honoured (i.e.
>> disable auto-capture), and would it have any impact (positive or
>> negative) on performance/memory usage? After several years of JS
>> closure ‘fun’ I kind of like that with PHP you only inherit the
>> variables you explicitly `use()` in closures.
> 
> Wouldn't there be just too many existing closures, which do not use
> `use` but (maybe) expect a clean scope?


The RFC is exclusively proposing single-expression short Closures.
We do NOT want multi-statement short Closures; it is a *feature* that generic 
Closures need an "use ($foo, $bar)".
This vastly improves readability and debuggability - it basically tells you 
whether the variables inside the code are imported or not. As Stephen Reay 
notes:
>> After several years of JS
>> closure ‘fun’ I kind of like that with PHP you only inherit the
>> variables you explicitly `use()` in closures.


So, auto-import for generic Closures definitely isn't an option.
Just on short, single-line Closures there is no benefit to "use ()", as EVERY 
variable used in the short Closure is supposed to be an imported variable. 
There is no point in forcing the user to distinguish between imported and local 
variable here.

Also, using "fn" in favor of "function" has the advantage of less clutter in 
one line. Compare

array_map(fn($x) => $x + 1)

to

array_map(function($x) => $x + 1)

The syntactical construction is already pretty clearly showing what's going on. 
The "function" keyword itself is already larger than the whole body. It 
distracts while reading the actual code.
Additionally, using "fn" is optically highlighting the fact that it's a 
short-Closure with auto-import and not a normal Closure with explicit import.

Thanks,
Bob

Re: [PHP-DEV] Change in type-hint representation

[Bob Weinand]

> Am 11.01.2017 um 17:37 schrieb Dmitry Stogov :
> 
> The patch was updated according to feedback: added comments, better names and 
> encapsulation, less magic, better code reuse, keep a free bit in zend_type 
> for future extension.
> 
> 
> 
> 
> 
> https://gist.github.com/dstogov/1b25079856afccf0d69f77d499cb0ab1
> 
> 
> Thanks. Dmitry.

Looks good so far…

Thought I've asked you before on IRC to somehow extract validation so that we 
don't have to duplicate it everywhere.

Validate (and cast if necessary) given a zval, strict mode and the 
representation type (class present as ce? as string?)

Also, perhaps a string representation of the type (reusable in reflection and 
in error messages)

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

Re: [PHP-DEV] Change in type-hint representation

[Bob Weinand]

> Am 11.01.2017 um 14:35 schrieb Nikita Nefedov :
> 
> On Wed, 11 Jan 2017 15:07:39 +0300, Dmitry Stogov  wrote:
> 
>> Hi,
>> 
>> 
>> I propose to introduce a unified type representation (zend_type).
>> 
>> Now it's going to be used for typing of arguments and return values.
>> 
>> Later we should use it for properties and other things.
>> 
>> 
>> https://gist.github.com/dstogov/1b25079856afccf0d69f77d499cb0ab1
>> 
>> 
>> The main changes are in zend_types.h and zend_compile.h, the rest is just an 
>> adoption for new type representation.
>> 
>> I don't think we need RFC, because this is just an internal change that 
>> doesn't change behavior.
>> 
>> 
>> I got the idea working on typed properties together with Bob and Joe.
>> 
>> https://github.com/php/php-src/compare/master...bwoebi:typed_ref_properties
>> 
>> I think it would be better to introduce zend_type and then continue work on 
>> typed properties.
>> 
>> 
>> Any comments?
>> 
>> 
>> Thanks. Dmitry.
>> 
>> 
> 
> Hey Dmitry,
> 
> Having worked on callable prototypes I'd say unifying PHP types in Zend
> is something we urgently need for PHP to continue evolving.
> 
> I'm not sure if PHP have ever been compatible with less-than-32bit
> archs but if it was I think it should be said that this would break
> such compatibility though.

PHP itself uses more than 2^16 bytes of memory… And we anyway have some code 
assuming that sizeof(void *) is a power of two. Hence we'll anyway need at 
least 32 bit.

> It would be great if there were some comment in the code near zend_type
> declaration where you'd explain how it is used and how additional
> data is being added to the pointer.

That's what the ZEND_TYPE_ENCODE_*() macros are for?

> Is there any use of ZEND_TYPE_CE() macro? It seems to be forgotten there?

Not necessarily in this patch, but in typed_ref_property branch reference types 
use the CE directly.

> If I understood this correctly, the layout of zend_type is as follows:
> 
>  [   ]    xxy0 - for IS_OBJECT type hint
>where the ``s are a (zend_string *) pointer and `y` designates
>an allow_null flag
> 
>  [   ]    xxy1 - for all other type hints
>where the ``s are a IS_CALLABLE, _IS_BOOL, IS_LONG, IS_DOUBLE,
>IS_STRING or IS_ARRAY

correct.

> Do we decide here that IS_REF modifier should belong to the concrete
> usages of the type (e.g. referentiality is a property of a variable
> and not of a type)?
> I'm not sure this if is a right decision or not but I feel like this
> question should be raised. It is usually the opposite in other languages.

We nowhere user-facing consider references to be a separate type, just 
internally for the zval representation (which was is_ref in PHP 5) - and as 
such being a reference is a property of the variable.

> How would you plan to extend this further? Let's say at some point we
> will have callable prototypes or generic classes: we will need to encode
> somehow this type into zend_type: `callable(A)` or `A`.
> Even right now it might be useful (as you suggest with ZEND_TYPE_CE)
> to store a (zend_class_entry *) instead of (zend_string *) when
> it is known to us in the zend_type.
> Seems like without extending zend_type to the size of two pointers
> it almost isn't doable :\
> Or, it could be made that zend_type, when it's not a simple type hint,
> would point to the `zend_type_complex` which would store a
> zend_class_entry pointer (or not, if it's for callable) and an array
> of type specifiers. But that introduces another indirection.

zend_type is just a typedef. If needed in future we may define it to occupy 2 * 
sizeof(void *) or such, just as we'll need it.
The goal of the patch is making type encoding transparent and handleable in a 
single place.
The current way of adding a new class of types usually was adding a new element 
to the relevant structs or similar hacks…

Bob

> Anyway thanks for polishing this part, we definitely need zend_type in some 
> form.
> 
> -- 
> 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] [RFC][VOTE] User defined session serializer

[Bob Weinand]

> Am 07.12.2016 um 21:07 schrieb Yasuo Ohgaki :
> 
> Hi Tony,
> 
> On Wed, Dec 7, 2016 at 7:17 PM, Tony Marston  > wrote:
>> "Yasuo Ohgaki"  wrote in message
>> news:caga2bxyax05jbjavyxfsjyy6xia+4u14npfgywscl4aoofq...@mail.gmail.com...
>>> 
>>> 
>>> Hi Marco,
>>> 
>>> Thank you for explaining the reason why!
>>> 
>>> On Mon, Dec 5, 2016 at 11:12 AM, Marco Pivetta  wrote:
 
 I voted "no" because I don't see any advantage over using a custom
 session
 save handler, besides adding more API that partially covers custom
 session
 save handlers.
>>> 
>>> 
>>> You mean current OO custom save handler, I suppose.
>>> 
>>> Firstly, current OO custom save handler design (use of previously used
>>> internal save handler as its base class) is not good. Overriding
>>> open()/close()/etc are useless, moreover harmful. Number of bugs
>>> proved it is not good.
>> 
>> 
>> I have been using session_set_save_handler() since 2002 to store all session
>> data in a database, and I have never encountered any problems. Why is it
>> "not good"? What bugs are there?
> 
> It works if it is used correctly. However, we've got number of bug
> reports for abuse/misuse cases. Refer to bugs.php.net  
> for details.
> 
>> 
>> I do not see the point in this RFC.
> 
> Did you read the RFC?
> It enables to write serializer by PHP script, clean and simple. It
> cannot be done by save handler.

We can just directly read from $_SESSION (in write) and use session_encode() 
(for returning on read()) as a workaround.
It isn't the cleanest way, but it works.

I appreciate a cleaner way, but it really should (see the last mail) cover 
everything, including the need to store to different locations.

> Besides, the reason why we don't have user defined serializer is
> "register_globals", the reason why we have problematic base class for
> OO API save handler is "register_globals".  We should get rid of
> obsolete features at some point also.

Could you please that explain further?
Also cleaning up obsolete features would be nice, rather sooner than later.

Bob

> Regards,
> 
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net 
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php 
> 

Re: [PHP-DEV] [RFC][VOTE] User defined session serializer

[Bob Weinand]

> Am 07.12.2016 um 21:49 schrieb Yasuo Ohgaki :
> 
> Hi voters,
> 
> Following people are vote against this RFC for now.
> 
> bwoebi (bwoebi)
> danack (danack)
> hywan (hywan)
> leigh (leigh)
> levim (levim)
> nikic (nikic)
> ocramius (ocramius)
> peehaa (peehaa)
> ryat (ryat)
> 
> I suppose bwoebi and levim vote against due to error and exception
> usage. Thank you for feedback, Levi and Bob.
> 
> How many of you vote "no" because of error and exception issue?
> 
> IMHO. Exception in session module is out of scope of RFC,  mixing
> error and exception in a module is confusing and inconsistent. Session
> module is not language engine, so I'm not 100% sure if we should use
> TypeError exception for normal module's invalid return type. However,
> I don't mind much to use exception if many of us insist.
> (BTW, "interface" parameter issue is out of scope this RFC also. It
> should be addressed by OO API cleanup RFC consistently. I'm trying to
> resolve issues one by one.)
> 
> I wonder how many of you understand this RFC is really a
> "register_globals" legacy cleanup? Do you really think we should keep
> "register_globals" legacy because of irrelevant issue?
> 
> Thank you for feedback!
> Unless there are feedbacks, nobody cannot figure out what's the reason
> behind for "no" votes.
> 
> Regards,
> 
> --
> Yasuo Ohgaki

Exceptions is one thing.

That's why I initially voted no.

Though thinking more about it, I still do not see the need.

session_set_save_handler() ultimately can just do the job completely.
Encryption? save_handler can do that.
Saving to somewhere else? It can do that.

Note that your RFC is not a replacement. Especially the last thing, saving to 
somewhere else, which isn't a file, cannot be prevented without it.

If there were:
save(string $uuid, array $data)
read(string $uuid): array $data

That'd make much more sense. Having to do flock() + file_get_contents() / 
file_put_contents() yourself to sys_get_temp_dir()."/$uuid" is not a problem in 
case you want to save it yourself.
Perhaps we should provide session_default_write(string 
$data)/session_default_read(string $data). I do not care too much.

And how is that related to register_globals?!

If this RFC were a proper replacement with also a proposed deprecation plan 
(e.g. in 7.4 (or 8.0) whatever comes first), that'd be a plus too. But 
currently it looks like we're heading to just have yet another separate system 
for sessions.

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

Re: [PHP-DEV] [RFC][VOTE] User defined session serializer

[Bob Weinand]

Hey,

> Am 06.12.2016 um 08:06 schrieb Yasuo Ohgaki :
> 
> Hi all,
> 
> *snip*
> 
> * Why it does not use exception for error?
> 
> Session module uses "errors", not "exceptions" basically. Session save
> handler uses "errors" also. We should avoid inconsistency in a module.
> Exception adoption will be addressed and exceptions will be used
> consistent manner by other RFC.

This is not session module specific, your interface is specifying a return 
type. Thus this should be enforced on the interface implementation level. (I.e. 
it will be impossible for an user to define a function not having a return type 
of string/array)

Also, if a wrong argument is passed to a function, it should throw a type 
error. Perhaps old modules from pre-PHP 5 do emit warnings or recoverables, but 
we then shall transition from that to TypeError, and definitely use TypeError 
in new functionality.

Bob

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

Hey there,

I’ve actually been working on an implementation covering also typed references, 
so that it’s possible to create references to a typed property, which had been 
a major concern back then.

See also: 
https://github.com/bwoebi/php-src/compare/typed_properties...bwoebi:typed_ref_properties

I’m planning to revive the RFC soon.

Bob

> Am 19.11.2016 um 15:04 schrieb Rasmus Schultz :
> 
> Heh, so, this week, a coworker of mine started using PHP 7, and he calls me
> over, and he's like, "I don't get it, I had heard PHP 7 was supposed to
> have type-hints now - it worked for return-types, but what am I doing
> wrong, I can't seem to get this to work for properties?"
> 
> He actually had something like "public int $id" in a class-declaration on
> his screen, and was genuinely confused - he simply assumed that would work,
> since it worked for return-types. When I explained to him that, no, PHP 7
> still isn't type-hinted, it's *more* type-hinted, but still not fully
> type-hinted, he gave me the lemon-face. You know the one. Like you just ate
> a lemon. Yeah.
> 
> I don't think there's a developer on my team and this point who isn't at
> least checking out other languages in frustration with the lack of features
> and consistency. I'm starting to feel like we're at risk of some of our
> best, young developers walking, if somebody offers them a chance to work
> with more "exciting" languages like Scala, Go, Dart, etc. - I'm not trying
> to say that proper type-hinting is the whole answer, but I believe it would
> go a long way towards consistency and the sense of completeness you get
> from some of the competing languages, where these features were engineered
> into the language from the design stage, rather than being added on a bit
> at a time.
> 
> Any plans to revive this RFC or is it officially dead?
> 
> 
> On Thu, Jun 23, 2016 at 11:08 PM, Pascal MARTIN, AFUP <
> mail...@pascal-martin.fr> wrote:
> 
>> Le 10/06/2016 12:38, Joe Watkins a écrit :
>> 
>>> The vote for typed properties has been restarted.
>>> 
>> 
>> Hi,
>> 
>> We, at AFUP, often tend to be on the "more static / strict types" side of
>> things, and it remains this way for this RFC -- which means we would be +1
>> for typed properties.
>> 
>> A few noted this was not quite "the PHP way", while the majority felt this
>> was in line with previous changes (like scalar type declarations, nullable
>> types...) and could prove interesting for complex applications.
>> 
>> Judging from where the votes are right now, I'm guessing this RFC will not
>> pass, but, in any case, thanks for your work on this!
>> 
>> There are more "yes" than "no", so maybe it will open a path towards
>> something, maybe a bit different, in another future version...
>> 
>> --
>> Pascal MARTIN, AFUP - French UG
>> http://php-internals.afup.org/

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

Re: [PHP-DEV] Feature Request: inline pseudo-instruction

[Bob Weinand]

> Am 4.10.2016 um 16:33 schrieb Pascal KISSIAN :
> 
>> -Message d'origine-
>> De : Lauri Kenttä [mailto:lauri.ken...@gmail.com] 
>> Envoyé : mardi 4 octobre 2016 16:21
>> À : Pascal KISSIAN 
>> Cc : internals@lists.php.net
>> Objet : Re: [PHP-DEV] Feature Request: inline pseudo-instruction
>> 
>> On 2016-10-04 14:33, Pascal KISSIAN wrote:
>>> I have an application where a small file is included at multiple 
>>> places.
>>> 
>>> The include is done about an average of 100.000 times .
>> 
>> I'm just wondering if you have ever heard of functions? You really should 
>> write a function, include it only once, and then simply call the function 
>> instead of repeatedly >including the file. Calling a function is a lot 
>> faster than including a file.
>> 
>> --
>> Lauri Kenttä
> 
> Function is not appropriate when the "inlined code" has to share 20-30 local 
> variables ...
> Having a function with 30 args,  or having to build and access an array is 
> not very efficient nor natural...
> Local variables include 6 nested "for loop" indices and local 
> variables/arrays needed for the computing.

Hey,

why do you think are your includes so slow?
Apart from the include itself (which in itself is fairly slow due to filesystem 
access; or in case with opcache, at the very least copying the op_array etc.), 
it does exactly this: building an array and importing it into the included 
files scope.

Also, 20-30 local variables? That sounds a bit like your code has way too many 
responsibilities in one same place. Perhaps you should restructure your code 
instead, but the way you describe it, no.

If your code is so "hot", that also even function calls would be quite 
significant then you should probably really inline your code there as a perf 
optimization. Anyway, code with that many variables almost always can 
meaningfully refactored.

It is not the languages task to optimize insane code ...

Bob

Re: [PHP-DEV] HashDoS

[Bob Weinand]

> Am 23.09.2016 um 03:16 schrieb Stanislav Malyshev :
> 
> Hi!
> 
>> The patch is not only targeting JSON. He just used JSON as an example.
>> 
>> Every function generating arrays with keys based on user-defined input
>> needs to be updated.
> 
> That looks like a very good way to make a lot of mistakes, miss a lot of
> cases and end up playing whack-a-mole with covering all functions. Why
> not just patch zend_hash.c and be done with it?
> 
> -- 
> Stas Malyshev
> smalys...@gmail.com 

Hey,

Note that the implementation is going to fallback to a fatal error if even more 
collisions are reached. (in the current patch: 1100 instead of 1000)

So, even if we miss some cases with the exceptions, there still will be a 
safety net for us.

We could patch zend_hash.c in two ways: SipHash (slw) or only fatals (very 
bad for e.g. servers written in PHP. When they have to decode some JSON, it's 
trivial for an attacker to crash them very easily). As that's not an option, we 
need to use exceptions.

Bob

Re: [PHP-DEV] HashDoS

[Bob Weinand]

> Am 22.9.2016 um 22:08 schrieb Stanislav Malyshev :
> 
> Hi!
> 
>> Yeah it introduces new functions for updating hash which is used by json
>> for updating array and it's also in std object handler which is used when
>> updating json object. For some other bits like updating array, it will stay
>> with fatal. The thing is that json parser can then easily check if there
>> was an exception and if so, it will set JSON_ERROR_DEPTH and clear it. It
>> seems much better though.
> 
> I'm not sure why special handling for JSON? JSON is certainly not the
> only way user data can be ingested and the problem of hash collision is
> common to all these ways.
> 
> -- 
> Stas Malyshev
> smalys...@gmail.com 

The patch is not only targeting JSON. He just used JSON as an example.

Every function generating arrays with keys based on user-defined input needs to 
be updated.

I’m going to update the patch soon and will notify you then.

Bob

Re: [PHP-DEV] [RFC] [Vote] Asynchronous Signal Handling

[Bob Weinand]

> Am 28.06.2016 um 18:41 schrieb Nikita Popov :
> 
> On Tue, Jun 28, 2016 at 6:16 PM, Dmitry Stogov  wrote:
> 
>> Hi internals,
>> 
>> 
>> The RFC has been moved into voting stage:
>> 
>> 
>> https://wiki.php.net/rfc/async_signals
>> 
>> 
>> Thanks. Dmitry.
>> 
> 
> What about Bob's suggestion to add a flag (for disabling async signals) to
> pcntl_signal() instead of having a global option?
> 
> In any case, imho the default for this should be on, not off. Default "on"
> matches the PHP 5 behavior better than "off".
> 
> Nikita

The reason I've chosen to not pursue this:

In the next major PHP version we may remove ability of manual signal handling 
and corresponding pcntl.async_signals INI directive or pcntl_async_signals() 
function.


Thus I don't see much sense in adding complicated logic (extra parameter) if 
we're anyway going to remove that.

After all, current sync handling can be changed to add to an array and then 
read the triggered signals from that array.
Thus synchronous handling can be abolished. The only reason we really needed 
true sync dispatching before was it not being too reliable and relying on ticks.

Bob

Re: [PHP-DEV] [RFC] Asynchronous Signal Handling (withiut TICKs and any additional overhead).

[Bob Weinand]

> Am 24.06.2016 um 12:20 schrieb Dmitry Stogov :
> 
> Hi internals,
> 
> 
> Please review the RFC https://wiki.php.net/rfc/async_signals
> 
> 
> Thanks. Dmitry.

Overall, I really like the approach.

I've thought a bit about the function vs. ini approach.

Advantage INI:
- Global setting, set it once, works everywhere

Advantage function:
- You are guaranteed one specific initial value and don't see surprises when 
one environment doesn't match your default and you forgot to explicitly 
enable/disable it.

The former one is good when you have your own scripts everywhere on the server, 
the latter is preferable when you are installing external applications.

An alternative approach would be adding a flag to pcntl_signal() whether it 
should be dispatched asynchronously or held back for synchronous dispatching 
(with async being the default).

I prefer that third option because of the following scenario:
a phpunit test with timeout testing an event loop. Event loops naturally want 
to enable synchronous dispatching, which obviously will hold back the signal 
and thus the alarm set up by phpunit will never be triggered if the test ends 
up in e.g. an infinite loop.

I'm not convinced by this solution, but it's the best one I can think of 
solving all the cases.

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

Re: [PHP-DEV] [RFC] [VOTE] Union types

[Bob Weinand]

> Am 14.6.2016 um 21:53 schrieb Levi Morrison :
> 
>> I'm personally against Union types because it makes no sense for classes
> 
> I've been over this before but I'll repeat it here for completeness:
> this is not true. Unions provide a way to discriminate between
> potential sets of types. Even among classes there is power in unions.
> Consider the idea of encoding a Something or Nothing with methods such
> as `map`, `flatmap`, `filter`, etc.
> 
> A Something will return a Something for map, and a Nothing will return
> a Nothing. By using inheritance there are two problems:
> 
>  1. We can create additional subclasses that do not obey the
> semantics of the type. Imagine how frustrating a stack that does not
> behave like a stack would be; same principle here.
>  2. We don't have covariant return types so we cannot express that
> Nothing::map will return Nothing and Something::map will return
> Something.
> 
> Using two final classes for Something and Nothing and then doing a
> union on them has neither of these downsides. Even if we add return
> type covariance we cannot solve problem 1.
> 
> Given that there are numerous other uses with built-in types such as
> Array | Traversable (iterable), int | string (array key), int | float
> (numeric) and so forth it does not make sense to me to special case
> these things. Generality is better for language features than special
> casing.

What Levi tries to explain: unions are like a temporary virtual super-interface 
to any accepted class without actually being implemented by them.

Typically you are writing adapters for these things, but an adapter is not 
always the solution (i.e. in cases where a part of the handling is identical, 
but depending on the actual class (instanceof) they ultimately get dispatched 
to somewhere else).
For exactly these cases (which, I admit, aren’t numerous [The cases where it’s 
legitimate and there is no other superior solution]) union classes are helpful.

Bob

Re: [PHP-DEV] [RFC] [VOTE] Union types

[Bob Weinand]

> Am 14.06.2016 um 20:35 schrieb Fleshgrinder :
> 
> On 6/14/2016 8:00 PM, Stanislav Malyshev wrote:
>> So we just held a vote on introducing ?type a month ago, to now vote on
>> removing it. Am I the only one to whom it doesn't make a lot of sense?
>> 
> 
> Exactly what I question too especially because the other vote was so
> overwhelmingly positive.


If we'd voted first on unions (and had a separate vote whether to allow null as 
type), I'm sure the vote would have been just as positive and the nullables RFC 
not appeared at all.

I'm personally guessing that people mainly wanted to see nullability _at all_ 
rather than the specific "?" syntax.

Thus there's a separate vote...

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

Re: [PHP-DEV] [RFC] [VOTE] Union types

[Bob Weinand]

> Am 14.06.2016 um 17:22 schrieb Derick Rethans <der...@php.net>:
> 
> On Tue, 14 Jun 2016, Bob Weinand wrote:
> 
>> It has been long enough under discussion... I've put union types into 
>> vote.
>> 
>> Please find the RFC located at:
>> https://wiki.php.net/rfc/union_types <https://wiki.php.net/rfc/union_types>
> 
> Not clear on some of the wording. When you say:
> 
> "This RFC proposes a vote on whether ?Foo shall be replaced by Foo | 
> null in general."
> 
> Do you mean that ?Foo will no longer be allowed at all if this RFCs 
> passes?
> 
> cheers,
> Derick
> 

Correct. I think there should be only one way to do that; others may disagree, 
hence it is a separate vote.

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

Re: [PHP-DEV] [RFC] [VOTE] Union types

[Bob Weinand]

> Am 14.06.2016 um 18:09 schrieb Fleshgrinder :
> 
> On 6/14/2016 5:22 PM, Derick Rethans wrote:
>> Not clear on some of the wording. When you say:
>> 
>> "This RFC proposes a vote on whether ?Foo shall be replaced by Foo | 
>> null in general."
>> 
>> Do you mean that ?Foo will no longer be allowed at all if this RFCs 
>> passes?
>> 
>> cheers,
>> Derick
>> 
> 
> Same question here, since https://wiki.php.net/rfc/nullable_types
> already passed and directly voiding it makes no sense.
> 
> I mentioned this before but maybe it is better to change the RFC to
> disallow the question mark if an union type is in use:
> 
> # OK
> 
> ?string
> null|string
> string|null
> 
> ?SomeClass
> 
> SomeClass|SomeOtherClass|null
> null|SomeClass|SomeOtherClass
> SomeClass|null|SomeOtherClass
> 
> # BAD
> 
> ?SomeClass|SomeOtherClass
> ?SomeOtherClass|SomeClass
> 
> ?string|int
> ?int|string
> 
> This would be a perfectly valid and reasonable restriction that makes
> sense in every way because it helps to avoid ambiguity. However,
> disallowing ?T is not.
> 
> -- 
> Richard "Fleshgrinder" Fussenegger
> 


These last ones (which you describe as "BAD" are anyway disallowed.

The separate vote is to remove ?string by string | null as only option.
(It basically just preserves the concept of nullability, but reverses the 
decision to use a trailing ?. This vote is in order to give those who prefer 
only foo | null instead of ?foo a chance to voice their opinion.)

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

[PHP-DEV] [RFC] [VOTE] Union types

[Bob Weinand]

Hey,

It has been long enough under discussion...
I've put union types into vote.

Please find the RFC located at:
https://wiki.php.net/rfc/union_types 

The vote is open until the 23th.

Thanks for voting,
Bob

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 13.06.2016 um 14:36 schrieb Christoph Becker <cmbecke...@gmx.de>:
> 
> On 04.06.2016 at 16:37, Bob Weinand wrote:
> 
>>> Am 4.6.2016 um 16:17 schrieb Christoph Becker <cmbecke...@gmx.de>:
>>> 
>>> On 04.06.2016 at 14:15, Bob Weinand wrote:
>>> 
>>>>> Am 04.06.2016 um 13:45 schrieb Niklas Keller <m...@kelunik.com>:
>>>>> 
>>>>> For Aerys\Host it could also be solved with an interface that just 
>>>>> doesn't have any methods. With the disadvantage of callable not being in 
>>>>> the same signature anymore.
>>>> 
>>>> Additionally, this is only possible if you are actually in control on 
>>>> these classes and can change them. If you pull them from a library, no 
>>>> chance.
>>> 
>>> In which case it might make sense anyway to use adapters.
>> 
>> For which you then need an adapter for each and every combination of 
>> interface (power set without empty set; 2^n - 1 - 15 adapter classes for 4 
>> interfaces).
>> That’s not a practical solution here.
> 
> After having a closer look at the referenced code[1], I agree.  However,
> in this case it would still be possible to avoid overloading the
> function by having a dedicated function for each type (i.e.
> useCallable(), useMiddleware() etc.)  That doesn't appear bad to me.
> 
> [1]
> <https://github.com/amphp/aerys/blob/2a4d626fb1b8b8ac9d91711085c04eaabdec7768/lib/Host.php#L87>
> 
> -- 
> Christoph M. Becker

Principally, yes, it's possible.

The reason we've chosen to not do this:
A class is often a module which may need to be callable, middleware and monitor 
at once. It allows us to have the user not know about what exactly he 
implements (in the sense of "this module is middleware and monitor"), but to 
just tell him "here's our module, just use() it and be done".
It eliminates the need of the user having knowledge of that. (=> user 
friendliness)

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 10.06.2016 um 16:24 schrieb Levi Morrison :
> 
> On Fri, Jun 10, 2016 at 6:37 AM, Dmitry Stogov  wrote:
>> Hi,
>> 
>> 
>> I hardly worked on implementation of this patch for a week, but I still 
>> don't like it.
>> 
>> It makes 15% slowdown on each property update in existing PHP code (without 
>> types), and I don't see a way to improve this.
>> 
>> Update of typed properties is going to be even more expensive.
>> 
>> Benchmark results are included into RFC (and not changed with the latest 
>> version of the patch).
>> 
>> 
>> -1.
>> 
>> 
>> Thanks. Dmitry.
>> 
>> 
>> From: Joe Watkins 
>> Sent: Friday, June 10, 2016 1:38:04 PM
>> To: PHP internals; Phil Sturgeon
>> Subject: [PHP-DEV] [RFC][Vote] Typed Properties
>> 
>> Afternoon internals,
>> 
>>The vote for typed properties has been restarted.
>> 
>>Please take part: https://wiki.php.net/rfc/typed-properties
>> 
>> Cheers
>> Joe
> 
> To clarify though, didn't Wordpress and Mediawiki see only a 0.1%
> slowdown? In my opinion that is definitely a tolerable performance hit
> for such a feature.

Right, the 15% are quite skewed … it's in a tight loop which means ideal L1 
cache utilization and the number of executed instructions for a runtime-cached 
ASSIGN_OBJ is very small. Where even 4 additional instructions make significant 
difference.
The 0.1% slowdown of WP and MW are painting a much more realistic (aka 
real-world) image. And as the RFC writes, "may be caused not by the additional 
checks but by the worse CPU cache utilization, because the size of PHP code was 
increased on 40KB". 
These micro-benches are really insignificant, especially as it is trivial (in 
tight loops) to work on a local CV and only assign it later to the property.

This IMO is really voting no for the wrong reasons...

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 10.06.2016 um 16:16 schrieb Niklas Keller <m...@kelunik.com>:
> 
> 
> 2016-06-10 16:12 GMT+02:00 Bob Weinand <bobw...@hotmail.com 
> <mailto:bobw...@hotmail.com>>:
> In this case a definite -1 on the RFC from me. I don't want "surprises" 
> regarding the type if a property is declared to return a certain type.
> 
> Where's the surprise?

Receiving a different type than I asked for. (as promised by the type decl)

Bob

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 10.06.2016 um 16:00 schrieb Niklas Keller <m...@kelunik.com>:
> 
> 2016-06-10 15:50 GMT+02:00 Bob Weinand <bobw...@hotmail.com 
> <mailto:bobw...@hotmail.com>>:
> 
>> Am 10.6.2016 um 15:34 schrieb Niklas Keller <m...@kelunik.com 
>> <mailto:m...@kelunik.com>>:
>> 
>>> 
>>> Top-posting, since I'm taking off now.
>>> 
>>> From outside the class, properties are not visible at all, so their types
>>> are un-important from outer scopes.
>>> 
>>> echo $foo->bar; is not the same in instance method body or outside of the
>>> class.
>>> 
>> From outside it works just fine and doesn't throw:
>> https://3v4l.org/L8CqF/rfc#rfc-typed_properties 
>> <https://3v4l.org/L8CqF/rfc#rfc-typed_properties>
> 
> This is an intermittent bug in the implementation.
> the RFC is explicitly mentioning that it should throw and throwing also is 
> the correct behavior here.
> 
> I don't think this is and should be a bug. I think it is the right behavior 
> if we choose to throw at all. 

In this case a definite -1 on the RFC from me. I don't want "surprises" 
regarding the type if a property is declared to return a certain type.

Bob

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 10.6.2016 um 15:34 schrieb Niklas Keller :
> 
>> 
>> Top-posting, since I'm taking off now.
>> 
>> From outside the class, properties are not visible at all, so their types
>> are un-important from outer scopes.
>> 
>> echo $foo->bar; is not the same in instance method body or outside of the
>> class.
>> 
> From outside it works just fine and doesn't throw:
> https://3v4l.org/L8CqF/rfc#rfc-typed_properties

This is an intermittent bug in the implementation.
the RFC is explicitly mentioning that it should throw and throwing also is the 
correct behavior here.

Bob

Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 05.06.2016 um 00:55 schrieb Andrea Faulds :
> 
> Hi again,
> 
> In an attempt to be constructive, I have implemented an alternative approach 
> to weak scalar type selection here:
> 
> https://github.com/krakjoe/php-src/compare/multi-types...TazeTSchnitzel:multi-types-roulette
> 
> Where there is no exact scalar type match, this patch uses an algorithm 
> originally suggested by Nikita, wherein we use rand() to pick which type to 
> cast to.
> 
> This is much simpler than having a type precedence matrix, and thus is easier 
> to remember and reason about. The choice of selection function means that no 
> particular use-case is privileged. Given PHP's scalar types are roughly 
> equivalent (after all, PHP juggles them freely), this apparently unorthodox 
> selection process should nonetheless produce sensible results in most cases.
> 
> Please tell me your thoughts!
> 
> -- 
> Andrea Faulds
> https://ajf.me/ 
This is the holy grail I was hunting for so long!

All my computational problems can be solved by a simple rand()!

In case nobody objects I'm going to merge that straight ahead into php-src 7.0 
(no need for master-only, after all it's no real BC break!).

Thanks a very much!!!

Bob

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 4.6.2016 um 15:48 schrieb Niklas Keller :
> 
> Massive is a nice hyperbole here...
> Sure, you can check it manually… but why not just always check it manually 
> then?
> You then loose possibilities to reflect on it, have static analysis rely on 
> code only [currently you always have to check docblocks when it's not 
> declared; definitely not an option for e.g. Optimizer], and a single 
> signature is generally easier to parse for a human.
> 
> Talking about reflection, I'm not happy with the currently proposed solution.
> 
> > ReflectionType::__toString() will now provide a full union type as string; 
> > e.g. “int | float | NumberObject”.

What should it return then, if not this? ReflectionUnionType provides a 
getTypes() method returning you an array of ReflectionType classes you can 
access for their individual type.

> That requires libraries like Auryn to manually parse that string now. It's no 
> longer possible to directly use __toString to get the class name. Isn't there 
> a better solution?

You’ll have to change your code to respect union types and eventually call 
ReflectionUnionType::getTypes() in case instanceof returns true.
There are already suggestions to give it a better structure (I can only 
reference 
https://www.reddit.com/r/PHP/comments/4m93s1/i_want_to_enhance_and_break_the_reflectiontype/
 

 here), but fixing this (along with proper nullable handling etc.) is outside 
of the scope of this RFC.

> What about ReflectionType::isBuiltin()? What will it return? Just false? True 
> if only built in types are used?

false. The individual ReflectionTypes in the array returned by 
ReflectionUnionType::getTypes() will be telling you what they are.

> I think allowsNull can be handled as is.

Correct.

Bob

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 4.6.2016 um 16:17 schrieb Christoph Becker <cmbecke...@gmx.de>:
> 
> On 04.06.2016 at 14:15, Bob Weinand wrote:
> 
>>> Am 04.06.2016 um 13:45 schrieb Niklas Keller <m...@kelunik.com>:
>>> 
>>> For Aerys\Host it could also be solved with an interface that just doesn't 
>>> have any methods. With the disadvantage of callable not being in the same 
>>> signature anymore.
>> 
>> Also, it requires you to inverse responsibilities. You'd have to specify a 
>> common super-interface on every single fundamentally unrelated interface 
>> (which are only indirectly related by the fact that they receive common 
>> handling in a single place). That's a clear anti-pattern.
> 
> I agree, but I can't see why using a union type would be much better, as
> you would still bundle up a bunch of "fundamentally unrelated
> interface"s in a single (union) type.  While I see a small benefit in
> the explicit notion of the union type in the function's signature, that
> would completely vanish if we introduce some kind of type aliases later
> (as already noted in the "future scope" section as potential improvement).

Even if we introduce type aliases, the aliases will still have to contain 
unions by then. (And then it’d be weird if you could use them in aliases decls 
but not inline … huh?)
Also, the interfaces are _locally_ handled the same (i.e. in the structure 
passing it forward), but in the big image they are not.

>> Additionally, this is only possible if you are actually in control on these 
>> classes and can change them. If you pull them from a library, no chance.
> 
> In which case it might make sense anyway to use adapters.

For which you then need an adapter for each and every combination of interface 
(power set without empty set; 2^n - 1 - 15 adapter classes for 4 interfaces).
That’s not a practical solution here.

Bob

> -- 
> Christoph M. Becker

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

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 04.06.2016 um 13:45 schrieb Niklas Keller <m...@kelunik.com>:
> 
> Bob Weinand <bobw...@hotmail.com <mailto:bobw...@hotmail.com>> schrieb am 
> Fr., 3. Juni 2016 23:31:
> 
> > Am 3.6.2016 um 18:49 schrieb Larry Garfield <la...@garfieldtech.com 
> > <mailto:la...@garfieldtech.com>>:
> >
> > On 06/03/2016 10:16 AM, Jordi Boggiano wrote:
> >> On 03/06/2016 15:58, Thomas Bley wrote:
> >>> To me type declarations help to make my code easier and more consistent.
> >>> Having multiple scalar types for a single function parameter is against 
> >>> this goal since I need extra logic to handle this.
> >>>
> >>> e.g. function foo(string | int | bool $bar) {} makes no sense in weak 
> >>> mode since string can already handle int, bool, float, etc.
> >>>
> >>> having different behavior between
> >>> foo("42"); function foo(string $b) {echo gettype($b);} // string
> >>> and
> >>> foo("42"); function foo(string | int $b) {echo gettype($b);} // integer
> >>> also makes no sense to me.
> >>>
> >>> Things like string|array are useful (e.g. str_replace) since we can cast 
> >>> the string easily to array and calling a string parameter with an array 
> >>> would give a fatal error.
> >>
> >> That is a useful case, and don't forget also return values, e.g. all the 
> >> XX|false-kind of return types it's also nice to have.
> >>
> >> I don't think for function arguments it's massively useful and I doubt 
> >> it'll get put everywhere, but it's nice to be able to express this when 
> >> you have to.
> >>
> >> Cheers
> >
> > For parameters, I really don't think | is going to be the common use case.  
> > (It should still be rational, but I don't expect to see it day to day.)  
> > InterfaceA & InterfaceB Is the more useful use case for parameters.  | is, 
> > as noted, likely more useful on returns. (even though I would discourage 
> > their use in most cases for reasons I won't go into here).
> >
> > --Larry Garfield
> 
> 
> It won’t and it should not be *common*. But there are legit uses cases:
> 
> https://github.com/amphp/aerys/blob/2a4d626fb1b8b8ac9d91711085c04eaabdec7768/lib/Host.php#L87
>  
> <https://github.com/amphp/aerys/blob/2a4d626fb1b8b8ac9d91711085c04eaabdec7768/lib/Host.php#L87>
>  
> <https://github.com/amphp/aerys/blob/2a4d626fb1b8b8ac9d91711085c04eaabdec7768/lib/Host.php#L87
>  
> <https://github.com/amphp/aerys/blob/2a4d626fb1b8b8ac9d91711085c04eaabdec7768/lib/Host.php#L87>>
> 
> This concrete example shows that a class may implement multiple concrete 
> interfaces which all get the same/similar behavior locally. [And somewhere 
> else the code checks for each element in the array what classes it implements 
> and marks them appropriately.]
> Sure, you could have ->addMiddleware($foo)->addRequest($foo) … or just a 
> single ->add($foo). It’s maybe not the most pure API, but the most practical 
> one.
> 
> But I agree, I myself would discourage usage of union types in most cases 
> too; but there *are* legitimate cases which shall be also properly typable. 
> Thus we need it.
> 
> Bob
> 
> I don't see where the massively added complexity justifies the very few edge 
> cases. That 1% can still be checked manually.

Massive is a nice hyperbole here...
Sure, you can check it manually… but why not just always check it manually then?
You then loose possibilities to reflect on it, have static analysis rely on 
code only [currently you always have to check docblocks when it's not declared; 
definitely not an option for e.g. Optimizer], and a single signature is 
generally easier to parse for a human.

Also, I don't believe it's the languages task to put arbitrary limitations on 
this. If a library does this, that's the libraries problem. But a language 
should not  do that and try to support full typing. We've decided to make PHP 
(opt-in) typed on function boundaries (and eventually soon on property storage 
boundaries), so we should also finish what we committed to instead of putting 
something half-arsed forward.

> For Aerys\Host it could also be solved with an interface that just doesn't 
> have any methods. With the disadvantage of callable not being in the same 
> signature anymore.

As you say, disadvantage of callable. Also, it requires you to inverse 
responsibilities. You'd have to specify a common super-interface on every 
single fundamentally unrelated interface (which are only indirectly related by 
the fact that they receive common handling in a single place). That's a clear 
anti-pattern.
Additionally, this is only possible if you are actually in control on these 
classes and can change them. If you pull them from a library, no chance.

Bob

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 3.6.2016 um 18:49 schrieb Larry Garfield :
> 
> On 06/03/2016 10:16 AM, Jordi Boggiano wrote:
>> On 03/06/2016 15:58, Thomas Bley wrote:
>>> To me type declarations help to make my code easier and more consistent.
>>> Having multiple scalar types for a single function parameter is against 
>>> this goal since I need extra logic to handle this.
>>> 
>>> e.g. function foo(string | int | bool $bar) {} makes no sense in weak mode 
>>> since string can already handle int, bool, float, etc.
>>> 
>>> having different behavior between
>>> foo("42"); function foo(string $b) {echo gettype($b);} // string
>>> and
>>> foo("42"); function foo(string | int $b) {echo gettype($b);} // integer
>>> also makes no sense to me.
>>> 
>>> Things like string|array are useful (e.g. str_replace) since we can cast 
>>> the string easily to array and calling a string parameter with an array 
>>> would give a fatal error.
>> 
>> That is a useful case, and don't forget also return values, e.g. all the 
>> XX|false-kind of return types it's also nice to have.
>> 
>> I don't think for function arguments it's massively useful and I doubt it'll 
>> get put everywhere, but it's nice to be able to express this when you have 
>> to.
>> 
>> Cheers
> 
> For parameters, I really don't think | is going to be the common use case.  
> (It should still be rational, but I don't expect to see it day to day.)  
> InterfaceA & InterfaceB Is the more useful use case for parameters.  | is, as 
> noted, likely more useful on returns. (even though I would discourage their 
> use in most cases for reasons I won't go into here).
> 
> --Larry Garfield


It won’t and it should not be *common*. But there are legit uses cases:

https://github.com/amphp/aerys/blob/2a4d626fb1b8b8ac9d91711085c04eaabdec7768/lib/Host.php#L87
 


This concrete example shows that a class may implement multiple concrete 
interfaces which all get the same/similar behavior locally. [And somewhere else 
the code checks for each element in the array what classes it implements and 
marks them appropriately.]
Sure, you could have ->addMiddleware($foo)->addRequest($foo) … or just a single 
->add($foo). It’s maybe not the most pure API, but the most practical one.

But I agree, I myself would discourage usage of union types in most cases too; 
but there *are* legitimate cases which shall be also properly typable. Thus we 
need it.

Bob

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 3.6.2016 um 14:18 schrieb Rowan Collins <rowan.coll...@gmail.com>:
> 
> On 03/06/2016 12:59, Bob Weinand wrote:
>>> function l(string | float $x) { echo gettype($x); }
>>> l("1.5a"); // I would expect string, but float would succeed if attempted
>> 
>> Exact matches *ALWAYS* match without coercion.
> 
> Gah, I keep making that mistake in my examples. I did say I was struggling to 
> get my head around things! ;)
> 
> I'm still missing an explanation of exactly where you derived the current 
> proposed rules from, though. The RFC just states "these rules are not an 
> invention of this proposal", but goes on to say "applies PHP casting rules in 
> a sane way", which implies some decisions were involved in drawing up these 
> rules.
> 
> I think you may be right that the rules are as simple as they can be, and I 
> don't want to waste too much of your time, but a basic summary of the 
> reasoning used would be much appreciated.
> 
> Regards,
> -- 
> Rowan Collins
> [IMSoP]

The *weak casting* rules (i.e. what gets converted how and what can be 
converted to the other type) are not an invention of the proposal.

The proposal however defines the specific order.

I’ve added a reasoning why not left-to-right now. As this seemed to be asked 
multiple times.

Also, the specific reasoning why I propose that specific order the rules are in:
> Otherwise PHP's casting rules are applied in an order to be as lossless as 
> possible.

That’s really the only motivation behind that.

Bob

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 3.6.2016 um 12:28 schrieb Rowan Collins :
> 
> On 03/06/2016 11:16, Thomas Bley wrote:
>> why not try all types weakly from left to right in weak mode?
>> Rule: if type check would give a fatal error for a type, try next type.
> 
> This is what I suggested, but Bob is insistent that weak mode should always 
> select the same type as strict mode where there is a valid strict match, 
> which I guess makes sense.
> 
> A strict left-to-right check violates that:
> 
> function i(string | int $x) { echo gettype($x); }
> i(10); // string in weak mode, int in strict mode
> 
> function j(int | string $x) { echo gettype($x); }
> j('10'); // int in weak mode, string in strict mode
> 
> 
> The main complication that I haven't quite got my head round yet is the fact 
> that an int->float coercion is allowed in strict mode. So to be consistent, 
> weak mode needs to privilege that cast:
> 
> function k(string | float $x) { echo gettype($x); }
> k(10); // float
> 
> But in other cases it doesn't seem sensible to privilege float over string:
> 
> function l(string | float $x) { echo gettype($x); }
> l("1.5a"); // I would expect string, but float would succeed if attempted

Exact matches *ALWAYS* match without coercion.

Emphasis from the RFC:
Primarily, this issue is *avoided if a parameter type exactly matches the input 
type* or if PHP is in strict type mode. 

> Regards,
> -- 
> Rowan Collins
> [IMSoP]



Bob

Re: [PHP-DEV] [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 03.06.2016 um 03:41 schrieb Sara Golemon <poll...@php.net>:
> 
>> On Thu, Jun 2, 2016 at 4:00 AM, Bob Weinand <bobw...@hotmail.com> wrote:
>> I know, it has been quite some time … but it's still well in time for 7.1.
>> 
>> Time to move on and put Union types to vote soon. [In the next 1-2 days]
>> 
>> We have done some changes to the RFC to emphasize the appeal of union types 
>> as well as clarified what exactly we will vote on.
>> 
>> If you have more feedback, it's welcome: https://wiki.php.net/rfc/union_types
> Would it be COMPLETELY antisocial at this point to ask for a secondary
> vote on this RFC for adding the "num" type which is an alias for (int
> | float) ?
> 
> -Sara

Not anti-social, but I won't add it...

The main concern is that it is an extra BC break (num is not too rare for 
class/namespace names I'd argue).
Additionally it warrants extra discussion. Num, Numeric? Which one?
Also proper elaboration why we should add it or not would have to be done...

I think this should be an own RFC thus.

Bob

Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 02.06.2016 um 22:25 schrieb Rowan Collins <rowan.coll...@gmail.com>:
> 
> On 02/06/2016 18:43, Bob Weinand wrote:
>> We had that exact idea relatively early, but it exposes other problems… 
>> order suddenly matters. You cannot just add "a" type and get the expected 
>> results.
>> 
>> E.g.
>> function f(true | string $foo) { ... }
>> 
>> everything except 0, ±0, "0" and "" would now return true. That's totally 
>> WTF. Sure, it's more friendly for people who want to read*rules*. But it is 
>> very bad for intuitivity.
> 
> I'm not so sure about that - the RFC already mentions the mnemonic that "|" 
> means "or", and anyone reading PHP code should be familiar with short-cutting 
> boolean operators, so this feels kind of natural to me: "$foo must be true OR 
> a string". Thus "I would prefer it to be true, but if not, will accept a 
> string".

This is a bitwise or (as in constant flags), where all modes are allowed. It's 
not a boolean or, whose mnemonic is "||" (not "|").

>> Also:
>> 
>>> >function i(string | int) { echo gettype($number); }
>>> >i('10'); // string
>>> >i(10); // string
>> This. This is especially bad as it has different behaviors in strict and 
>> weak mode then. That's a no-go.
> 
> Again, the logic is "I would prefer a string if you can, but an int if not"; 
> if weak mode tries its best to match that specification, it will always land 
> on a string coercion.

And again, in strict mode, this would result in an integer - but not in weak 
mode. (because strict types mandates no cast). This is a no-go, no matter what.

> It's more of a problem the other way around, though, because I'd forgotten 
> that weak mode is allowed to perform lossy casts:
> 
> function f ( int | string $number ) { echo $number; }
> f('1a');
> 
> In weak mode, this would echo "1", because the int cast succeeds, lossily. 
> That's a little odd, I admit.
> 
> 
> The rules are much clearer in table form, by the way, thumbs up for that. :) 
> Although it would be nice to point to some documentation of where these rules 
> were lifted from, given the claim that "they are not the invention of this 
> proposal".

E.g. object->string is possible right now and is preserved (but object->int 
etc. aren't).
Or a non-numeric string cannot be passed to neither int nor float; thus not 
possible to pass them to int|float. 

> Looking at them, I see there is one extra rule which doesn't seem to be 
> consistent with normal weak typing, but is trying very hard to be lossless, 
> and that's "float -> int (if lossless)" as a separate priority from "float -> 
> int".

I'm not strictly opposed here. If more people agree here I may change that.

> Current loose typing performs no such check:
> 
> function f(int $x) { echo gettype($x), ':', $x; }
> f(4.5); // integer:4
> 
> But the proposal is that this will prefer a string a cast:
> 
> function f(int | string $x) { echo gettype($x), ':', $x; }
> f(4.5); // string:4.5
> 
> If you get rid of this extra rule, the order of checks actually becomes a 
> simple priority order, regardless of source type: [exact match], int, float, 
> string, boolean.
> 
> 
> If the aim is to be lossless, then perhaps the order could be tweaked to make 
> lossy casts always lower priority: string, float, int, boolean? That's 
> technically lossy when passing int(9007199254740993) to "float | int" because 
> it's above the safe threshold of 2^53, but the current implementation is 
> already lossy when passing it to "float | string":
> 
> function f(float | string $x) { var_export($x); }
> f(9007199254740993); // 9007199254740992.0

Yes, but this same behavior we have with strict types and we shall adhere to 
that.

Bob

> 
> Regards,
> 
> -- 
> Rowan Collins
> [IMSoP]

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

Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 02.06.2016 um 21:43 schrieb Fleshgrinder <p...@fleshgrinder.com>:
> 
> On 6/2/2016 9:40 PM, Bob Weinand wrote:
>> is_numeric() is returning a boolean (that's the condition). $str+0 does 
>> conditionally cast to int or float (whatever the string specifies).
>> 
> 
>  php -r 'var_dump("foo" + 0);'
>  int(0)
> 
> This is what I am referring too. Shouldn't this crap result in an error?
> 
>  is_numeric($x) || throw TypeError('no no');
> 
> -- 
> Richard "Fleshgrinder" Fussenegger
> 


Oh, well… Better now?

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

Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 02.06.2016 um 20:53 schrieb Fleshgrinder <p...@fleshgrinder.com>:
> 
> On 6/2/2016 8:45 PM, Bob Weinand wrote:
>> Done that, does it look better now? :-)
>> 
> 
> Absolutely in my opinion, looks much simpler now. :)
> 
>> only if actually numeric, the result of $str + 0
> 
> Shouldn't we use is_numeric_string() here?

That's the internal function responsible for the conversion.

Bob

> -- 
> Richard "Fleshgrinder" Fussenegger
> 


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

Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 02.06.2016 um 19:52 schrieb Fleshgrinder <p...@fleshgrinder.com>:
> 
> On 6/2/2016 7:37 PM, Bob Weinand wrote:
>> Hey,
>> 
>> I think this is more of a presentation problem.
>> As you say, there's not much a better way to do that.
>> 
>> It's basically our weak casting rules, just applied to the most lossless 
>> type available.
>> It's out weak casting rules which are so complex; the RFCs combination is 
>> not particularly complex.
>> It needs to cover everything, but it's particularly important for the 
>> trivial cases to be handled here. Would be quite WTF if you could not pass a 
>> float to something accepting int (as one of its types).
>> 
>> I'd welcome every suggestion to make the rules look less scary, because they 
>> actually aren't.
>> 
>> Bob
>> 
> 
> Don't you think this matrix would be a better presentation and simpler?
> 
> |||||
> | type   |   #1   |   #2   |   #3   |
> |||||
> | bool   | string | int||
> | int| string | float  | bool   |
> | float  | string | int| bool   |
> | object | string |||
> | string | float  | int| bool   |
> |||||
> 
> Everything else is a TypeError.

Done that, does it look better now? :-)

> Note that I try string first all the time. Simply because it makes no
> difference for PHP afterwards, e.g.:
> 
>  function f(string|int $a) {
>if ($a == 1) echo 'foo';
>  }
> 
>  f(true); // true ~> '1' ~> 1 = foo
> 
> Even if the change I applied is not intelligent and is not a good idea
> (haven't thought about it deeply), the presentation as a table should
> help a lot.

There is one reason, it must not be inconsistent with strict types. Switching 
from strict_types=1 to strict_types=0 shall always work without semantics 
changes (as long as you don't catch TypeErrors).

> -- 
> Richard "Fleshgrinder" Fussenegger


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

Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 02.06.2016 um 19:33 schrieb Rowan Collins :
> 
> On 02/06/2016 18:11, Andrea Faulds wrote:
>> That aside, the behaviour the RFC now specifies for how weak typing
>> interacts with union types is frighteningly complicated. I don't see how
>> it could be anything other than that, but the new complexity this
>> introduces to PHP is enough for me to vote against this RFC, even
>> ignoring my other concerns.
> 
> That is rather a long-winded set of rules, I agree. I wonder if it's possible 
> for the order the union type is defined to be taken into account? That way 
> you could specify the rule thus:
> 
> * The type is tested against each type in the union in turn.
> * If weak typing is active, scalar types will be coerced where this would 
> normally be allowed, and passed over where a TypeError would be thrown.
> * If strict typing is active, scalar types will be treated the same as 
> non-scalar types, and must match precisely.
> 
> 
> So:
> 
> function f(int | float $number) { echo gettype($number); }
> f('10'); // int
> 
> function g(float | int $number) { echo gettype($number); }
> g('10'); // float
> 
> function h(int | Foo | string) { echo gettype($number); }
> h('10'); // int
> h(new Foo); // object
> h('hello'); // string
> 
> function i(string | int) { echo gettype($number); }
> i('10'); // string
> i(10); // string
> 
> This last example is the only one that might be a bit surprising - the "| 
> int" in the type def is actually doing nothing - but there's always scope for 
> user error.
> 
> 
> In strict mode, things would be a bit different, because no coercion is 
> allowed:
> 
> declare(strict_types=1);
> 
> function f(int | float $number) { echo gettype($number); }
> f('10'); // [!] TypeError
> 
> function g(float | int $number) { echo gettype($number); }
> g('10'); // [!] TypeError
> 
> function h(int | Foo | string) { echo gettype($number); }
> h('10'); // string
> h(new Foo); // object
> h('hello'); // string
> 
> function i(string | int) { echo gettype($number); }
> i('10'); // string
> i(10); // int
> 
> 
> It may be that the implementation makes this prohibitively difficult, but it 
> would certainly be easier to document than the rules currently proposed.
> 
> Regards,
> -- 
> Rowan Collins
> [IMSoP]

We had that exact idea relatively early, but it exposes other problems… order 
suddenly matters. You cannot just add "a" type and get the expected results.

E.g.
function f(true | string $foo) { ... }

everything except 0, ±0, "0" and "" would now return true. That's totally WTF. 
Sure, it's more friendly for people who want to read *rules*. But it is very 
bad for intuitivity.

Also:

> function i(string | int) { echo gettype($number); }
> i('10'); // string
> i(10); // string

This. This is especially bad as it has different behaviors in strict and weak 
mode then. That's a no-go.

The current way is the only viable one, as far as we discovered.

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

Re: [PHP-DEV] Re: [RFC] [PRE-VOTE] Union types

[Bob Weinand]

> Am 02.06.2016 um 19:11 schrieb Andrea Faulds <a...@ajf.me>:
> 
> Hi Bob,
> 
> Bob Weinand wrote:
>> Hey all,
>> 
>> I know, it has been quite some time … but it's still well in time for 7.1.
>> 
>> Time to move on and put Union types to vote soon. [In the next 1-2 days]
>> 
>> We have done some changes to the RFC to emphasize the appeal of union types 
>> as well as clarified what exactly we will vote on.
>> 
>> If you have more feedback, it's welcome: https://wiki.php.net/rfc/union_types
> 
> I do wonder if 1-2 days is really sufficient time, given that before now, the 
> only announced RFC had been substantially less complete.
> 
> That aside, the behaviour the RFC now specifies for how weak typing interacts 
> with union types is frighteningly complicated. I don't see how it could be 
> anything other than that, but the new complexity this introduces to PHP is 
> enough for me to vote against this RFC, even ignoring my other concerns.
> 
> Thanks.
> -- 
> Andrea Faulds
> https://ajf.me/


Hey,

I think this is more of a presentation problem.
As you say, there's not much a better way to do that.

It's basically our weak casting rules, just applied to the most lossless type 
available.
It's out weak casting rules which are so complex; the RFCs combination is not 
particularly complex.
It needs to cover everything, but it's particularly important for the trivial 
cases to be handled here. Would be quite WTF if you could not pass a float to 
something accepting int (as one of its types).

I'd welcome every suggestion to make the rules look less scary, because they 
actually aren't.

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

Re: [PHP-DEV] [RFC] Replace "Missing argument" warning with "Too few arguments" exception

[Bob Weinand]

> Am 02.06.2016 um 14:11 schrieb Dmitry Stogov <dmi...@zend.com>:
> 
> 
> 
> On 06/02/2016 03:01 PM, Bob Weinand wrote:
>>> Am 01.06.2016 um 12:55 schrieb Dmitry Stogov <dmi...@zend.com>:
>>> 
>>> hi,
>>> 
>>> 
>>> Please take a look into the proposal.
>>> 
>>> 
>>> https://wiki.php.net/rfc/too_few_args
>>> 
>>> 
>>> The RFC is extremely simple (both proposal and implementation) and almost 
>>> completely described by the email subject.
>>> 
>>> I think, this mini-RFC doesn't need 2-weeks discussion period, so I'm going 
>>> to start the vote on next week.
>>> 
>>> 
>>> Thanks. Dmitry.
>> Very nice!
>> 
>> Just a question: Does the RFC also impact calls to internal functions? (With 
>> internal functions we don't have the problem as they're typically 
>> immediately aborted, but it would be inconsistent with userland functions to 
>> have once a warning, once an exception)
>> 
>> Judging from the patch this isn't the case? (at least I see no related 
>> changes)
>> 
>> Thus I think the scope of the RFC is a bit too small. [and at least it 
>> should be explicitly mentioned in the RFC if you decide against that].
>> 
>> Bob
> The RFC doesn't propose to change behavior of internal functions.
> In case of wrong number of arguments, they are not executed anyway.
> It may make sense to change their behavior as well, but I don't see a big 
> value.
> 
> Thanks. Dmitry.

Right, then the RFC should explicitly mention it. It only talks about "function 
calls" in general right now, but doesn't restrict the scope to userland 
functions only.

The value is basically in having equal and consistent behavior (in failure 
case) for all functions.
I do not see it a must, but it would be a very-nice-to-have in my eyes.

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

Re: [PHP-DEV] [RFC] Replace "Missing argument" warning with "Too few arguments" exception

[Bob Weinand]

> Am 01.06.2016 um 12:55 schrieb Dmitry Stogov :
> 
> hi,
> 
> 
> Please take a look into the proposal.
> 
> 
> https://wiki.php.net/rfc/too_few_args
> 
> 
> The RFC is extremely simple (both proposal and implementation) and almost 
> completely described by the email subject.
> 
> I think, this mini-RFC doesn't need 2-weeks discussion period, so I'm going 
> to start the vote on next week.
> 
> 
> Thanks. Dmitry.

Very nice!

Just a question: Does the RFC also impact calls to internal functions? (With 
internal functions we don't have the problem as they're typically immediately 
aborted, but it would be inconsistent with userland functions to have once a 
warning, once an exception)

Judging from the patch this isn't the case? (at least I see no related changes)

Thus I think the scope of the RFC is a bit too small. [and at least it should 
be explicitly mentioned in the RFC if you decide against that].

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

[PHP-DEV] [RFC] [PRE-VOTE] Union types

[Bob Weinand]

Hey all,

I know, it has been quite some time … but it's still well in time for 7.1.

Time to move on and put Union types to vote soon. [In the next 1-2 days]

We have done some changes to the RFC to emphasize the appeal of union types as 
well as clarified what exactly we will vote on.

If you have more feedback, it's welcome: https://wiki.php.net/rfc/union_types

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

Re: [PHP-DEV] [RFC][Vote] Typed Properties

[Bob Weinand]

> Am 25.05.2016 um 23:56 schrieb Stanislav Malyshev :
> 
> Hi!
> 
>> var_dump($a->w); // Fatal error, uninitialized...
> 
> This means every read access to a property should be checked for it
> being typed, and every access to a typed property should be checked for
> it being initialized. I'm concerned there might be a performance hit for
> this.
> 
> Also, this means no access for a property - even defined one - is safe,
> and if you want to avoid fatal errors, you need to check every access,
> at least if you suspect typed properties may be involved. And, of
> course, there's no function in the RFC to actually check it.
> -- 
> Stas Malyshev
> smalys...@gmail.com

Hey Stas,

this is pretty much a non-issue (perf-wise) as we anyway need to check against 
IS_UNDEF to emit a notice and return null, even with normal properties.

Also, property access never was safe. Consider:

$obj = new class {
public $foo;
function __construct() {
unset($this->foo);
}
function __get($prop) {
throw new Exception("No $prop for you today!");
}
};
var_dump($obj->foo); // exception.

isset() checks will continue to work. It's just about getting a *value*. (and 
to check whether it's a typed property, there's Reflection support in the RFC.)

This definitely is no problem.

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