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

[Stanislav Malyshev]

Hi!



That is something PHP is missing atm, no one can verify the build
process for releases.


Yes that's what I was suggesting. This should be done by RM. In that 
way, the RM becomes more someone that verifies the build and not the 
actual person that provides the build.


I'm not sure though how the RM can really verify it. I mean, we have the 
tar blob that comes from the git repo - which we assume is legit. We 
also have some files that aren't in the repo. If RM builds them by 
themselves then the question comes up what if RM's environment is 
compromised and something bad is injected. If RM receives the files from 
outside source, how the RM verifies they are genuine?  I don't think 
reading through the whole "configure" file and verifying it's not bad is 
realistic for any person. And from what I understand, "configure" and 
such are quite environment-dependant, so you can't just have a standard 
hash to compare to. You can't have the RM to just run "buildconf" again 
and do hash check because they may get different bits than the ones 
coming from the outside, like CI. I dunno, maybe if we had some kind of 
Docker image for generating it that would produce reproducible result, 
that'd be possible? Otherwise I am still not sure how the verification 
procedure looks like.


Right now as I understand we're simply trusting the RM that they have 
uncompromised environment and third parties have no way to verify it's 
the case. But I guess it's time we do better?


Thanks,

Stas

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

[Stanislav Malyshev]

Hi!

On 3/30/24 1:27 AM, Sebastian Bergmann wrote:

Am 30.03.2024 um 05:17 schrieb Ben Ramsey:
This is also why our release managers sign the tarballs with their own 
GPG keys, after generating the artifacts. This verifies the release 
manager was the one who generated the files.


But does the release manager generate the files (and the tarball) in a 
reproducible way?


I understand that's what ./scripts/dev/makedist and 
./scripts/dev/genfiles do, but I suspect exact bits in resulting 
configure and lexers may depend on the exact version of tools & utils 
used. For upstream packagers like distros I'd likely recommend using 
these tools directly anyway, and not rely on what's in the package.


--
Stas Malyshev
smalys...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Change the edge case of round()

[Stanislav Malyshev]

Hi!


I've voted no, but only because I think that because this is
technically a documented (through RFC) BC break, it should wait for
PHP 9, and not for any 8.*.


I think so too, it's a frequently used function, and while the argument 
for the change look convincing, changing it an advanced point version 
still sounds like not a good idea.


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Security Audit Priorities

[Stanislav Malyshev]

Hi!


This reminds me of something.
There's an interesting paper about ReDoS resilience in different regex engines.
Some programming languages, including PHP, are evaluated there and compared: 
https://www.usenix.org/system/files/sec22-turonova.pdf
PHP has some configuration knobs for pcre 
(https://www.php.net/manual/en/pcre.configuration.php), not a lot to tune but 
maybe they can be?
To be honest, I haven't looked much into this.


Interesting topics, but I think not the top priority for the security 
audit, due to the fact that in PHP common use, regexps rarely come from 
a third party, and if they do (e.g. if you're writing a RE-driven search 
engine) you'd probably have potentially expensive searches anyway and 
thus make some ways to deal with it.


In general, I think there are two security aspects we're dealing with - 
one is guarding PHP user from a hostile third party, and another is 
guarding PHP developer from writing the code that may expose the end 
user. I think the former is the higher priority, though both are 
ultimately important.


Thanks,
--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Moving PHP internals to GitHub

[Stanislav Malyshev]

Hi!


I think what could be proposed instead is to enable GitHub discussions for
discussing ideas before they are proposed on the mailing list. It could be


Don't see any problem with that if somebody would be willing to keep an 
eye on it and do the moderator duties (unfortunately, any public forum 
requires that from time to time).


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Moving PHP internals to GitHub

[Stanislav Malyshev]

Hi!

  I'm not sure why it's assumed that participating in discussions is the 
same as actually developing PHP. I'm sure there are plenty of folks 


Right. And participating meaningfully requires some level of commitment 
and investment. For example, willingness to familiarize oneself with 
some very simple rules and follow them. If that's not for you, that's 
fine - there are many other interesting things to do on the internet. 
But it's not a problem.


why internals mails list is open to the public? So they the public can 
actually collaborate on the open source product they're using?


Yes. And "collaborate" means mutual labor. Part of the labor on the site 
of the new participant is to get familiar with the rules of the 
community. They are not very hard, extensive or complicated. Very little 
effort is required. But yes, non-zero effort - that's the 
"collaboration" part.


"Likes" wasn't my intention. There's no point in wasting countless hours 
on an RFC if it's clear ahead of time that it's not going to pass; and 
right now, even within this thread, it's hard to predict that. And, 


Don't predict - just ask people. If it's any good, you're guaranteed 
plenty of engagement, if anything, frequently too much of it.


choice. While not perfect in any sense, reactions provide a meaningful 
simple way of communicating this relevance with a simple thumbs up/down.


Simple? Yes. Meaningful? Meh.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Moving PHP internals to GitHub

[Stanislav Malyshev]

Hi!


  - having to subscribe to a mailing list to even see the discussions


Not really, there are archives.


  - having to learn the specific, uncommon rules of replying: bottom


If learning a couple of very simple rules is too much for you, maybe you 
are too busy to take on yourself another responsibility such as 
participating in PHP development. Encouraging drive-by commentary is not 
something that is a goal here.



  - no formatting, especially code blocks. Sure, they are possible through
HTML, but there's no single common way which all of the emailing clients
will understand - like Markdown


If you have code to contribute, feel free to use pull requests. The list 
is for discussion, and the short blocks appropriate in a discussion 
would do fine with simple copy-paste.



  - no reactions - it's hard to tell whether something is supported or not.


It's not Instagram. Collecting likes is not the goal. If the vote needs 
to be held, we have the RFC process.



Based on those issues and PHP, I propose moving the discussions elsewhere -


I am not really very active anymore on the development side but I would 
say it would make it strictly worse to move the discussion. Especially 
on Github which is not very suitable for such things - it is suitable 
for sharing and managing code.


Also, there already are Slack channels for PHP - and you can create 
another one if you feel like it (or a group on any other social 
platform, if many existing groups are not enough).



What are your thoughts?


Not a good idea.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] LDFLAGS broken?

[Stanislav Malyshev]

Hi!


There seems to be another unset done to this change here:
https://github.com/php/php-src/commit/c4d84aa33390045cd4ff542719a0f79cff52fb7c
which fixed some bugs related to linker errors and duplicate symbols.


Smells like people doing random things until some bug disappears...
and no commit messages here either, no explanation for the change.


Are you familiar with the principle called "Chesterton's fence"?

It could be these changes do not make sense. It also could be they are 
necessary for the build to work on one of dozens of systems, distros and 
tools combinations PHP is being built on. Unless you have tested on all 
of them, I'd advise caution there.


--
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] garbage in bugs.php.net

[Stanislav Malyshev]

Hi!

Somebody have put a ton of garbage reports in bugs.php.net under 
security bugs. Cleaning them up manually is kind of annoying, could 
somebody with DB access go in and clean them all up? They all have 
either OS or Summary field set to "1" as far as I can see.


Thanks,

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: [RFC] Migrating to GitHub issues

[Stanislav Malyshev]

Hi!


I had enabled that some weeks ago, since there has been a spam attack on
bugsnet, so we could test the new feature.  I probably should have
written to list right away, or at least have kept an eye on it, but I've
assumed to be notified about reported issues.

I'll have a closer look at the rather verbose report tomorrow, if nobody
beats me to it.


I was planning to take a look at it over the weekend, but do not let it 
to deter you :)


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Stanislav Malyshev]

Hello all,

I do not know if anybody here knows much about me personally, but I was 
born in Ukraine, lived there for all my youth and my relatives and 
friends are still there. You can imagine my feelings about this horrible 
attack on Ukraine that is going on right now.


I am sincerely and wholeheartedly thankful to everybody supporting the 
people of Ukraine in this terrible time, either by speaking out or by 
helping materially, monetarily or otherwise. If you want to help more, 
please look here: 
https://docs.google.com/document/d/1agAW4CQEdi5cDCSa8l8C5ez6Yflz5zaVIzMEgehqwq0/edit
or seek other charities that are helping Ukrainian people now. Your help 
is most appreciated.


That said, I am not sure whether it is a good idea to turn PHP site into 
a forum for political announcements. Even if they are of the most 
righteous and benevolent type. I am not exactly opposed to the idea, as 
I can not be opposed to any expression of support, but I feel it may not 
cause much good (certainly won't convince anybody, if the sights of 
rockets and shells destroying hospitals, kindergartens, churches, 
apartment buildings, maternity wards, and so on didn't) and there are 
better ways to express your support - such as contacting your local 
political representative, if you live in a democratic country, and/or 
using the links above, or donating your time and technical expertise to 
one of the relied efforts (I imagine some of them could use a skilled 
web developer).


That said, if somebody were to design a logo version with Ukraine flag 
and put it on PHP site, I don't think anybody in Ukraine would be 
offended by it...


Sorry if it sounds a bit confused, these are challenging times.
--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Stanislav Malyshev]

Hi!


The RFC is about deprecation, not removal.


If it's not going to be removed, what's the point of annoying people 
with deprecation warnings (that they would patch out/silence anyway)?


If we want to document which functions are recommended to be used in 
which case, we have the manual for that. I don't think deprecation 
should be used for such things.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] RFC proposal to deprecate crypt()

[Stanislav Malyshev]

Hi!

On 2/19/22 6:03 PM, st...@tobtu.com wrote:

crypt() should be deprecate because it can be used to create bad password 
hashes:


I don't think it's a good reason for deprecating functions. A lot of 
functions, if used incorrectly, could produce bad results, it's not the 
reason to not use them correctly.



Since password_verify() and password_needs_rehash() already supports hashes 
created with crypt(), the only thing needed to do is remove crypt().


Removing it would cause serious BC issues with no practical gain.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key

[Stanislav Malyshev]

Hi!


I don't think this behavior should be considered as "normal" and would like
to propose to change this for PHP 9, as it's a BC-break. To me it can and


It'd not be just a BC break, it'd be an absolutely massive BC break that 
has a potential to break a ton of code and would be extremely hard to 
detect. This is not something that should be changed in an advanced 
version of the language.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)

[Stanislav Malyshev]

Hi!

On 12/17/21 9:43 AM, Matt Fonda wrote:

Hi Jordan,

Thanks for the RFC. I have a couple questions:

Suppose I have classes Foo and Bar, and I want to support the following
operations:

- Foo * Bar (returns Foo)
- Bar * Foo (returns Foo)

If I understand correctly, there are three possible ways I could implement
this:


And that's one of the reasons I feel so uneasy with this. When reading 
this code: $foo * $bar - how do I know which of the ways you took and 
where should I look for the code that is responsible for it? When I see 
$foo->times($bar) it's clear who's in charge and where I find the code. 
Terse code is nice but not at the expense of making it write-only.


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)

[Stanislav Malyshev]

Hi!


3. I am already aware of several people within internals that believe any
version of this feature will result in uncontrolled chaos in PHP codebases.
I think this is false, as I do not see that kind of uncontrolled chaos in
the languages which do have this feature. However I would think that
allowing arbitrary overloads would increase that proportion.


Depends on how you define "uncontrolled chaos". I have encountered 
toolkits where the authors think it's cute to define "+" to mean 
something that has nothing to do with mathematical addition (go read the 
manual for an hour to figure what it actually does) or for += to mean 
something different than + and assignment. Some people even learn to 
love it, so far I haven't.



However, once a feature is added it is very difficult to change it. Not
only for backward compatibility reasons, but for the sheer inertia of the
massive impact that PHP has. I do not plan on ever proposing that arbitrary
symbol combinations be allowed for overloads myself. But I cannot possibly
know what internals might think of that possibility 10 years from now when
this feature has been in widespread usage for a long time. Using magic
methods makes it extremely difficult at *any* point in the future to allow
PHP developers the option of an overload for say +=+. What would such a


That's awesome. The only thing worse than a toolkit author that thinks 
it's cute to play with "+" is the one that thinks it's cute to invent 
some random combination of special characters and assign it some meaning 
that of course is obvious to the author, but unfortunately that's the 
only person in existence to whom is it obvious. Some people enjoy the 
code being a puzzle that you need to untangle and make a sherlockian 
detective work to even begin to understand what is going on in this 
code. Other people have work to do. And again, what's the intuitive 
difference between operators +=+@-+ and ++--=!* ?


Of course, of course I know, every feature can be abused. The difference 
here is that if it's hard to think about any use that wouldn't be an abuse.



That sounds far *less* maintainable to me. It seems more likely that even
if it were a desired feature 10 years from now, it would be something that
would be extremely difficult to implement, maintain, and pass.


I must notice "if" carries a lot of load here.
--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: [RFC] Migrating to GitHub issues

[Stanislav Malyshev]

Hi!

> With Laminas, we use an email alias to allow researchers to report to us.
> We then post the full report as a security issue on GitHub - it's a 
feature

> they rolled out late 2019/early 2020 that restricts visibility to
> maintainers initially, but allows inviting others to collaborate (we 
invite

> the reporter immediately, for instance). It also creates a private branch
> for collaboration. When the patch has been merged, you can mark the issue
> public.
>
> If the plan is to move to GH anyways, this could solve security 
reporting.


Not familiar with it, but on the initial look it seems it could work, 
with one caveat. We have a ton of reports which aren't security issues 
and some which need to be discussed before we are sure which one is that.


We could do it on the list, of course, but that creates the same dangers 
as mentioned before - too easy to lose info in an un-archived ML.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Unbreak git.php.net links?

[Stanislav Malyshev]

Hi!

On 10/3/21 9:48 PM, Joe Watkins wrote:
I just realised you're probably talking mostly about links in old 
comments on bugs rather than in source code of bugsnet (because they 
would be easy to find).


Maybe permanent redirects aren't so bad in that case.

But also, can't we just update the comments in place?


Well, that's possible too but I imagine it'd be more work.

--
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Unbreak git.php.net links?

[Stanislav Malyshev]

Hi!

I know we're no longer using git.php.net, but there are a lot of links 
there e.g. in bugs system. I wonder how hard it would be to make 
git.php.net redirect links like this:


http://git.php.net/?p=php-src.git;a=commit;h=3c939e3f69955d087e0bb671868f7267dfb2a502

to something like:

https://github.com/php/php-src/commit/3c939e3f69955d087e0bb671868f7267dfb2a502

--
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Spam on bugs.php.net

[Stanislav Malyshev]

Hi!

I notice that we have increased amount of spam coming in to 
bugs.php.net. I'm not sure if anyone is maintaining it right now - but 
it'd be nice to have changes to counter that - I see that anti-spam 
measures exist on some forms but not on adding comments to closed bugs 
for some reason. And also maybe add ability to delete comments at least 
for some people, so it can be cleaned up.


Thanks,
--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Stanislav Malyshev]

Hi!


The crux of the issue is what our end goal is:

1. Require users to explicitly annotate classes that use dynamic
properties, but otherwise keep dynamic properties as a fully supported part
of the core language.
2. Remove support for dynamic properties entirely. The core language only
has declared properties and __get/__set, and nothing else. stdClass is just
a very efficient implementation of __get/__set.


I think goal (1) is reasonable for the long run, and goal (2) is taking 
it a bit too far for PHP.


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Request for karma to vote on RFCs

[Stanislav Malyshev]

Hi!


I think PHP’s biggest strength is its large and active community. But
in my opinion, PHP (source/internals) often miss to benefit from our
great community. I am happy to help making changes, but I feel like
it is an impossible task for me… I mean, I cannot even update an
outdated wiki entry.


Why it's an impossible task for you and why it's related to voting? I
don't think you need voting access to fix docs or propose patches.


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: open_basedir?

[Stanislav Malyshev]

Hi!


Apparently, there has been no resolution for this issue so far.  While I
don't really care about the open_basdedir directive per se, I fully
agree that we should not advertize it as security feature, and to
clearly state this in the PHP manual, as well as in our security policy.


Correct. As I mentioned, de-facto it's already the case for years now. 
Let's fix the docs at least? Though I'd really start thinking about 
maybe removing it in the next major version...

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Stanislav Malyshev]

Hi!

No I don't agree.  People can do whatever is convenient for them.  Some 
will top-post; Some will bottom-post and some will inter-post.  By 
interpost I mean people will try to respond to a post on a point by 
point basis.


The thing is when you alone, you're free to do what is convenient to you 
and ignore the rest. However, here we have a community that needs to 
communicate, and we may want to make it convenient to others to read our 
messages, sometimes to people that are new to the discussion and need 
some context to understand and participate. And our experience on this 
list shows that top-posting does not serve this goal. So we decided to 
ask people to not top-post.


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: Bugsnet

[Stanislav Malyshev]

Hi!

It might just be an illusion, but it feels like all three projects have 
a lot more resources to spend on all this than PHP does; Rust has 
"Working Groups", Kubernetes has "Special Interest Groups", and PHP 
struggles to assign each module a single maintainer. How that affects 
our tooling requirements, I'm not sure, but I suspect new contributor 
experience should be high on our priority list, either in terms of user 
interface or just documentation.


Great survey. I do not have much experience with others, but from my 
observations about Prow it's a software system of its own which needs 
its own configuration, setup, maintenance, and everything else that's 
involved in setting up and maintaining CI/CD system. Github provides a 
nice GUI for it but there's much more that is happening behind the 
scenes than the GUI. Prow itself is pretty nice to use, once you learn 
how to work with it, but we need to be aware that if we want something 
with Prow capabilities, we'd need somebody willing to support this 
system, so we're back to the same place we departed from.


--
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Re: Bugsnet

[Stanislav Malyshev]

Hi!

If at some time in the future, github becomes a less than suitable 
environment for us, we can just move, no problem. There's no sense in 
which we are locked into anything.


I don't see how we could "just move" if all our bug handling would be 
wired into Github. I can easily see how we could move a repo to any 
provider that supports git - git is a generic platform, Github is just a 
frontend. But there's no alternative frontend for Github Issues that we 
could just copy the data into - you move, you lose your existing system. 
 There are probably import tools on some platforms, but the processes, 
assignments, etc. - all will have to be re-developed, even if we could 
re-use the raw data.


--
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Re: Bugsnet

[Stanislav Malyshev]

Hi!

Quite aside from spam problems, bugsnet is hidden away in a dark corner 
of the internet that requires a special login, doesn't integrate with 
source code or our current workflow (very nicely), and doesn't get 
updated or developed.


Having moved our workflow to github, now seems to be the time to 
seriously consider retiring bugsnet for general use, and using the tools 
that are waiting for us - Github Issues.


I know my opinion here probably doesn't carry a lot of weight since I am 
not the one maintaining bugs day to day (and probably don't have much 
time to allocate to it) but that's what I've got.


It is not good that our infrastructure is "hidden away in a dark 
corner", and it is true that bugs needs some TLC for a while. But Github 
Issues frankly sucks big time as a bug management system. It's hard to 
fault them as it's not their core business - but while it may be 
adequate for a small project, I don't see how Github system could be 
manageable with any serious volume. Let me list all it is lacking that 
we have right now, with current old and dusty bugs:


1. Bug reporting template
2. Pre-filter on reported bugs
3. Advanced search
4. Custom fields like PHP version or CVE ID
5. Private bugs that are accessible only to members of security team
6. Custom statuses (I guess can be worked around with labels, but would 
require a lot of work to make it convenient to use, default screen would 
be pretty much unusable due to clutter, as it only understands closed/open)
7. Ability for anybody to submit a bug without opening github account 
(yes, I know it also produces the spam problem) and assigning bugs to 
people that don't have github account (we still can accept patches from 
those, can't we?).

8. Statistics

It may be over optimistic, but we might get better engagement with bugs 
on github than anywhere else also - Github is where people are tending 
to do their business today.


I think it's way to generic statement. Some people choose github for 
doing some stuff would be more accurate. I don't think I can remember 
from the top of my head any major project that uses Github as their main 
bug tracker. Maybe they exist, but I certainly can't recall any.


Github is maintained, hosted, developed, and free, and while it isn't 
the perfect tool for the job, nothing else is either. We could spend 
time (which we don't have) developing bugsnet, or installing some other 
solution in a dark corner of the internet, and solve no problems at all, 
and be burdened with the ongoing maintenance of that solution.


Why we must install it in a dark corner? Maybe we should ask for some 
help from people who are willing to contribute before we decide to scrap 
the whole thing.


Besides that, I am not sure I am feeling that comfortable with moving 
100% of the infrastructure of the PHP project to a platform wholly owned 
by Microsoft, and that's where things seem to be heading. I know 
Microsoft is almost not evil now, and it has no problem with PHP 
whatsoever, but things change, and who knows what would happen in 
another 5-10 years. I am not sure hard-binding the whole project to a 
single platform owned by a single company is that great. Due to the 
distributed nature of Git, the repository hosting is very low risk - it 
could be easily moved anywhere. But having the rest of the 
infrastructure in a single point of failure does not feel great. Once we 
move in there, it would be very hard to move out.


Maybe it's just my paranoia speaking, but I think this is also something 
we should be considering.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] PHP Language Specification

[Stanislav Malyshev]

Hi!


I wonder what to do with the PHP Language Specification[1].  Apparently,
the repo is abandoned (last commit was more than a year ago, although
PHP 8 changed quite some stuff).  If we don't have the bandwidth to
maintain it, we should mark it as unmaintained, and maybe some of the
information could be moved to the PHP manual  (I quite like the strict
syntax specification, which the manual almost completely lacks).


The old stuff I think is still valid, but would be nice if somebody took 
on themselves to update it. I think the spec and the manual are 
different documents, for different audiences, so having separate spec 
would be a good thing. However, we should have clear demarcation which 
parts applies to which version and which parts are missing.


--
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Re: [PHP-CVS] [php-src] master: Fix build warning

[Stanislav Malyshev]

Hi!

On 4/27/21 1:11 AM, Nikita Popov wrote:

Author: Nikita Popov (nikic)
Date: 2021-04-27T10:10:22+02:00

Commit: 
https://github.com/php/php-src/commit/310c0561a9e5ec9a0414654cc96fb2b3c7e1abc7
Raw diff: 
https://github.com/php/php-src/commit/310c0561a9e5ec9a0414654cc96fb2b3c7e1abc7.diff

Fix build warning

This causes the build to fail on PHP-8.0 and higher.

Changed paths:
   M  ext/imap/php_imap.c



Weird, I saw the warning but the build worked just fine for me. Are 
there different options somewhere on CI?


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] wiki.php.net upgrade

[Stanislav Malyshev]

Hi!

Nobody has updated the wiki in several years, despite warnings, and two 
very public breaches of security that we know about.


I think it's just because nobody has focused attention to it. As you 
see, once it was focused, it has happened.


Thanks,
--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] wiki.php.net upgrade

[Stanislav Malyshev]

On 4/8/21 7:44 AM, Niklas Keller wrote:

Hey all,

the wiki is up to date now with the help of @Sergey Panteleev 
. :-)


Thank you both!
--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] wiki.php.net upgrade

[Stanislav Malyshev]

Hi!

If we want to keep using wiki.php.net then, sure, we should update it. 
We could also migrate the wiki to GitHub.


We also already have https://github.com/php/php-rfcs which we could use 
for RFCs instead of a wiki going forward.


Wiki isn't used only for RFCs, there's more content there than that. I 
personally think wiki serves these use cases much better than Github would.


--
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] wiki.php.net upgrade

[Stanislav Malyshev]

Hi!

Given that we're upgrading and updating our infrastructure, maybe it's 
time to update the wiki.php.net wiki too? I count five upgrade warnings 
there now, and I am not sure, but I think we could assume there were 
some bugfixes in it since 2017.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Raising the precedence of the new operator

[Stanislav Malyshev]

Hi!

On 4/5/21 9:40 AM, André Hänsel wrote:

I was wondering... PHP is the only language I know of where you have to
write `(new Foo())->bar()` instead of
`new Foo()->bar()`. This is particularly apparent with the builder pattern:


Enabling something that is syntax error now sounds pretty innocent, but 
I wonder if messing with precedence would cause some deeper consequences 
in different expressions. We need to be careful here given how much code 
(and how much weird code) there exists in PHP. If we can guarantee that 
we can enable this construct without causing any side effects, then it's 
fine I think.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Changes to Git commit workflow

[Stanislav Malyshev]

Hi!

On 3/29/21 4:49 AM, Max Semenik wrote:

On Mon, Mar 29, 2021 at 1:53 AM Nikita Popov  wrote:


changes should be pushed directly to GitHub rather than to git.php.net.



Would it also make sense if direct pushes (bypassing the pull requests
system) were disallowed completely? I can see multiple problems with direct
pushes:


This is possible. In fact, there are Git bots that make it easier (e.g. 
prow: https://github.com/kubernetes/test-infra/tree/master/prow) - I am 
using such system over Github at my $DAYJOB and it's generally working 
well. It even has its own built-in karma-like system. However, it has 
some downsides, as the experience shows:


1. Quick management patches, typofixes, release management patches, etc. 
become more high friction processes.
2. Setup and configuration of such system involves some time investment 
by some knowledgeable people, and it has certain learning curve (though 
once it is set up, it's pretty easy to use).
3. Somebody knowledgeable needs to maintain it, as periodically bots can 
get stuck and need a gentle kick to continue.
4. CI needs to be very stable and clean for having CI pass as gateway to 
merge, otherwise a flaky test can block all work in the repo for days.

5. Managing multiple active branches can be a pain.

None of these are critical, and we could start small and build it 
incrementally, of course.


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1

[Stanislav Malyshev]

Hi!

> date_sunrise() and date_sunset()

Do we have any information on usage? I am generally not a fan of 
deprecating functions that work - even if they are odd and have quirky 
APIs - but if the usage is essentially zero than it might be ok.


> key(), current(), next(), prev(), and reset() on objects

I'd be happier if those worked with iterators. Except for prev() which I 
don't think many people need.


> mb_check_encoding() without argument

No objection.

> get_class(), get_parent_class() and get_called_class() without argument

I'm not sure why. I mean if we want to make them return the same as 
self::class etc. - up to the point of actually compiling them as such - 
no problem, but I don't see why they need to be deprecated. And I 
vaguely remember seeing get_class() at least a bunch of times in old 
code, when ::class didn't even exist. I don't see a good reason why that 
code should be broken.


> FILE_BINARY and FILE_TEXT constants

No objection.

> t fopen mode

I'm afraid there's - despite the warning - a bunch of code for Windows 
that relies on "t" and I don't think we should be breaking it. Is there 
a good reason to drop this mode?


> Passing bool for $amountOrUpOrDown argument of IntlCalendar::roll()
> Accessing static members on traits

No objection.

> strptime()
> strftime() and gmtstrftime()

We have to remember many applications do not need to be portable, as 
they will ever be only run on one setup - the one that the company 
running it has. So non-portability itself should not be a fatal problem. 
I am worried by musl thing mentioned - what exactly happens on musl, 
they don't have strptime()? If it's just different outputs or some 
options not supported, I think it's ok - warning in the docs should be 
enough.


> mhash*() function family

No objection.

> ctype_*() function family accepts int parameters

Here I think adding notice for int arguments would be appropriate, but 
changing the behavior is not - we could cause some very nasty breaks in 
the code if we suddenly change such a basic thing.


> Return by reference with void type
> NIL constant defined by the IMAP extension

No objection.

> Calling overloaded pgsql functions without the connection argument

I hate global state, but there are a lot of old quick-n-dirty scripts 
relying on stuff like that. Can we maybe check how common is usage of 
this pattern?


> $num_points parameter of image(open|filled)polygon
> mysqli::init()

No objection.
--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Don't compare zero exponentials in strings as equal

[Stanislav Malyshev]

Hi!


PHP's == comparison semantics for strings have a peculiar edge-case, where
comparisons of the form "0e123" == "0e456" return true, because they are
interpreted as floating point zero numbers. This is problematic, because
strings of that form are usually not numbers, but hex-encoded hashes or
similar.


This particular argument makes sense, but in more generic sense I feel 
it leads us to a dangerous path of implying it's ok to use "==" to 
compare strings, because we'll take care of the corner cases. Which I 
think is wrong to imply because there are so many corner cases where it 
still doesn't work and probably never will. I mean, "000" == "000" 
is still true. "010" == "010" is still true. "1e23" == "001e023" is 
still true. Nobody who applies == to strings and expects it to work out 
as stri g comparison is doing the right thing. If you apply == to 
hex-encoded hashes, that code is fubar, and fixing one particular corner 
case won't rescue it. So I wonder if fixing one particular corner case 
while leaving many others in would do much.


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Travis CI migration?

[Stanislav Malyshev]

Hi!


Any news here?  Tomorrow PHP 7.3.27 will be tagged, likely without any
Travis-CI build to confirm that it's not broken on Linux.


As far as I can see, it's migrated to .com, but we're currently out of 
free credits. Not sure how we run through them so fast, we may need to 
adjust the cron settings there or reach out to them and ask for OSS 
credits. I am a bit busy today but maybe could write tonight or somebody 
else could do it. We may also try to limit the users allowed to trigger 
the builds...


I have however a 7.3 build here: 
https://travis-ci.com/github/smalyshev/php-src/builds/215525375 that 
looks fine.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Abusive emails was: silly question : what is more secure at the moment, php7, php8, or plain .sh shell scripts?

[Stanislav Malyshev]

Hi!


He's also apparently has been emailing people individually off-list
according to: https://news-web.php.net/php.internals/112833

If anyone else receives unpleasant emails from him (or from anyone
else), please either:

* forward them to the list for all to see.
* forward them to myself, if you'd prefer to not have it dealt with in public.


I have received some less-than-polite emails from Reindl Harald, but I 
don't think I'll bother finding them and forwarding them, because I 
think there's no point (unless somebody can convince me there is). I am 
a big boy and I can deal with it (mostly by ignoring the person being 
rude, email is excellent this way - I don't ever have to read a message 
from somebody who I know is not able to behave in a civilized way). And 
if it were about me that would be the end of it, however, this seems to 
be widespread both in time and in number of people affected, so I think 
it is about time to take action and remain without further contributions 
from Harald in the future.
I am the last person to propose silencing somebody for expressing 
unpopular thoughts or ideas, but there's a difference between thinking 
outside the box, right or wrong, and just being rude. The latter helps 
no one.


Thanks,
--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Travis CI migration?

[Stanislav Malyshev]

Hi!


The exception being the PHP-7.3 branch, which in security mode.  Unless
we add GH CI for that branch as well, switching to travis-ci.com seems
to be useful.  Maybe we get enough free credits for the relatively rare
builds?


I don't think it's possible to migrate only one branch, but if we 
migrate the whole repo and use cron-only builds for upper branches, and 
request OSS credits if we run out of free ones, I think we should be OK.


Given that we have 7.3 still which aren't supported by Azure as I 
understand, I think we should migrate the repo but not invest too much 
into making it work for 8.x, just make it work for more infrequent 7.x 
builds. I'm not sure how credits work there yet, but I think we could 
ask enough of them to have 7.3 and maybe even 7.4 supported and not 
worry too much about the rest.


--
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Travis CI migration?

[Stanislav Malyshev]

Hi!

Today I noticed the message on travis-ci.org:

Please be aware travis-ci.org will be shutting down in several weeks, 
with all accounts migrating to travis-ci.com. Please stay tuned here for 
more information.


As far as I know, our repo is still not migrated. Anybody looked into it?

Also, as I understand, the .com builds will be managed used credits 
system, with OSS getting allocated credits: 
https://docs.travis-ci.com/user/billing-faq#what-if-i-am-building-open-source
but this has to be done manually. I can reach out to them but wanted to 
ask first in case somebody already did.


Looks like we need to take care of it pretty soon or we risk losing 
access to the CI.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

[Stanislav Malyshev]

Hi!

While it's clear that passing e.g. an array falls into the scope of that 
general note, it doesn't say anywhere on that page that a string value 
which contains "\0" is "not what it expects", and I don't think I would 
ever have guessed that before reading this thread.


So I stand by my assertion that this behaviour was both undocumented and 
unexpected.


You may assert anything, but it's a fact that PHP functions have 
returned nulls on bad values since forever. The manual may tell you not 
to rely on that, but that's still what they did. It's not like it 
suddenly happened out of nowhere. It has been the case for ages.


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

[Stanislav Malyshev]

Hi!


Just to reiterate, the previous implementation was also bad - it
returned an entirely undocumented and unexpected null value.


PHP functions always returned null on bad parameters, so it's not
exactly unexpected.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Strict switch

[Stanislav Malyshev]

Hi!


I'm referring to support for non-trivial expressions, aka blocks. Say, the
ability to split up a long expression by using a meaningful temporary
variable. Block support is sufficient to cover *most* switch use-cases,
obviating the need to introduce a new switch variant.


We could take a page from Scala book and designate a return value to a 
block (of course, no reason to bother if it's not used) - which should 
make it relatively easy to add blocks in any expression context.


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

[Stanislav Malyshev]

Hi!

yeah, you should think about external input *before* do anything with 
it, always! if you pass a random path with NULL you did not do anything 
to validate the input


Yes, and? is_file should be safe (as in, not exploding and breaking the 
whole app) on any input (leaving typing discussion aside, any string 
input). It should return true if the input is a name of an existing 
file, false otherwise. It's simple, not?


millions of security issues in whatever programming language are the 
result of "i throw the input somewhere and don't mind"


This is a general banality which is not applicable to this specific 
functions. Sure, there are security issues that come from input 
validation failure. It is not the case here. As somebody who added those 
checks in most of the code personally, I can tell you not bailing out 
but returning false on is_file would not make security of this function 
worse in any way.


I know why it happens - because it has been treated as a type error 
(which was a nice hack but in retrospect probably not the most correct 
way) and then we decided to make type error throw and the fact that this 
is not actually a type came to bite us in the butt. I think the solution 
for this is to refactor this code and separate null checks from type 
checks. It was a nice hack for the time, but its time has expired.


if you ever reach that exception you have a stacktrace up to the point 
where you should have stopped proceed at all


Nope, there's no reason to stop processing when I check whether a random 
string signifies valid files. There might be a reason to stop processing 
later, after I discovered it is not, or continue processing, depending 
on the code intent - e.g. use alternative filename, or the default, or 
different code path. Exploding functions take this ability from me as an 
author of the code. So I will be forced to take it back by replacing 
every use of is_file with safe_is_file which would catch the exception 
and return false. Which just adds work for me which I hadn't to do 
before. That's not how the language should evolve - it shouldn't make 
things that are now easy harder.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

[Stanislav Malyshev]

Hi!


we are running error_reporting E_ALL for 17 years now and don't
distinct between notice / warning / error, it has to be fixed -
period


Surely you do. Your code continues to run after warning/notice but stops
after the error. It's impossible to ignore that. Unless you have an
error handler that does exit() after a notice (which I have hard time
believing, honestly, but who knows), there is a very major distinction.

It's not about what "has to be fixed" - it's not about the contents of 
your bug tracking database - it's about the code that run one way and 
suddenly now runs (or, rather, fails) in a fundamentally different way.


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

[Stanislav Malyshev]

Hi!


First, assuming that a null byte in a file name *is* an error condition, is
the PHP 8 behavior better than in PHP 7? I think the answer to this one is
very clearly "yes". The above code snippet and the subtle way in which it


For me as a user that would be a very clear "no". Now if I have any 
usage of these functions in my existing code, I have to go and replace 
them with safe wrapper to ensure it doesn't bail out in random places. 
It may be the same for functions like fopen() where you have to 
error-check anyway, but for functions like is_* it's strictly worse. In 
fact, I am struggling to find a scenario where it's better for me as a 
user from the code robustness PoV - it's either the same or worse.



is broken is a great illustration of that. PHP 8 makes it obvious that the
cited code is incorrect.


But it's not incorrect. if is_file("abc\0") returns false, it's correct 
- "abc\0" is not a correct filename, so I expect it to return false. It 
does exactly what I need, so it's correct.



Second, should a null byte in a file name be an error condition in the
first place? This is a point I'm not sure about. It would certainly be
possible to treat paths containing null bytes as non-existing paths, and
abstract away the fact that paths cannot contain null bytes, and that this
is a common attack vector.

I'd personally lean towards not considering null bytes an error condition.


This is a kind of philosophical question, like whether or not trying to 
open a file that doesn't exist is an "error condition". Throw-happy 
languages like Java think it is, other languages like C or PHP treat it 
in different way. But I think in any case what we've got in 8 with is_* 
is not an improvement.


--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: PHP 8 is_file/is_dir input handling

[Stanislav Malyshev]

Hi!


So why having is_file()/is_dir() throw a warning for the past 8 years
(since PHP 5.4) a non-issue? Because by that logic it shouldn't


Warning is a debugging functionality. Throwing is breaking the app and 
stopping the whole process. There's a fundamental difference between the 
two.



Would it have been fine if this would have been a TypeError as it was
originally intended?


It's not a type error. PHP does not support such types. "string that is 
a valid filename" is not a type in PHP, thus TypeError would be misleading.



Is a warning fine because null bytes indicate a potential attack as in no
sane
context should null bytes be passed around?


A warning is fine because it does what it's supposed to do - fails the 
is_file check (which is literally only there to check if this string 
specifies a valid filename) while not breaking the app. Exception breaks 
the app.


So what we'll be seeing very soon is people creating userspace safe_is_* 
wrappers that would work around this "functionality", working against 
the language instead of being helped by it. This is not how it should be.

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] PHP 8 is_file/is_dir input handling

[Stanislav Malyshev]

Hi!


In PHP 7, this returns FALSE:

php -r 'var_dump(is_file("ab\0c"));'

In PHP 8, the same code throws a ValueException. Problem is now that


I think this is a mistake. Exceptions should not be thrown on such 
values, it only breeds boilerplate code (now you'd have to wrap each 
call to is_* into try/catch or add another pre-call validator just to 
ensure it doesn't throw). PHP type system is not robust enough to 
support fine-grained types like "string that has certain format", and 
pretending we do have this as a type and throwing typing error on it 
only makes the consumer work harder for no additional gain. In almost 
every situation I can imagine, string that is not the name of the file 
is equivalent to string that is not the name of the file and also has \0 
in it. However, this setup forces me to treat them differently and add 
additional validation step to it. While to some functions it may be a 
useful functionality - specifically to constructor functions expected to 
return an object, so they can't really tell "you gave me invalid data" 
other than throwing - for something like is_file it will only be annoying.

--
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Decoding cookie names

[Stanislav Malyshev]

Hi!

In one of the bug reports there was a question raised - should PHP be 
decoding cookie names? Right now it does. The standard is pretty much 
silent on this, and looks like such behavior leads to security problems: 
https://hackerone.com/reports/895727


However I am not sure whether it's ok to change it, since it fails a 
couple of tests (easy to fix) and may also break some stuff I have no 
idea about. In general, using url-encoded cookie names is very weird, 
but I can't guarantee nobody does it. So, I wonder what exactly should 
we do in this case?


RoR folks just changed the code to not decode cookies.
Also, php_setcookie() does not seem to encode cookie names (note: we're 
talking names not values here!) when we send them out, so maybe it 
doesn't make sense to decode them when we receive them?


What do you think?
--
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Wiki upgrade?

[Stanislav Malyshev]

Hi!

Could somebody take care of upgrading the wiki software? It now displays 
5 "new release" banners on each page, and it's quite annoying...

--
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Stanislav Malyshev]

Hi!

> If it adds a micro-optimization, great, but allowing a developer to
> explicitly signal intent is the primary argument for adding void.
> IMO.

You can signal intent by using $_ or $dummy or whatever. You don't need
new language construct each time for each way of using or not using a
variable.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values

[Stanislav Malyshev]

Hi!

>> In theory, this should be a general performance win any time one
>> needs to iterate over only the keys of an iterable, because it does
>> not require the use of an O(n) iteration and building of the array
>> that array_keys() would, plus it works on non-array types (such as
>> generators or iterators). It also is more performant than
>> foreach($iterable as $key => $_) {}, because it omits the opcode
>> that instructs the engine to retrieve the value. (Presumably, a
>> future direction could include using this request to inform
>> generators or

To me, it looks like the case of premature micro-optimization. Unless
there's a benchmark that proves it achieves speedup in a real-life
application (not tight-loop synthetic benchmark) I think
foreach($iterable as $key => $_) {} is completely fine. My opinion has
been and remains, absent new data, that if your code performance hinges
on a couple of simple opcodes being there, maybe you'd better implement
that part in C, but in most real-life applications it is not and any
performance gain you might get from such syntax is microscopic.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Session mm support

[Stanislav Malyshev]

Hi!

> I've recently found out that compiling PHP with --with-mm has a massive
> negative impact on PHP startup performance (approximately 3-4 times
> slower), to the point that our CI got approximately 2x slower overall with
> it enabled. This is not great.

That's weird. Would be nice to run a profile to see what makes it so
slow. From a quick look on the code it just creates a shared memory
segment, which shouldn't be that expensive...

> As I only found out about the existence of this session backend recently,
> I'm wondering how widely it is used, and whether we wouldn't be better off
> dropping it from php-src. The performance characteristics make it a pretty
> big foot-gun.

It's probably not that well known, especially as I'm not sure underlying
library is well maintained (it has been last updated in 2006 but maybe
it's still good and doesn't need any updates?) but I'd give it a chance
by at least trying to see what's up. If it proves hard then we may think
about dropping it.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Community vote on RFCs

[Stanislav Malyshev]

Hi!

> How many people have voting rights? Over 200 if I'm not mistaken? How
> many of those have been activly contributing to PHP for over the past
> year? I think that's a better question to answer. If half of those
> people's voting rights get revoked then maybe there's room to allow a
> few more key community figures to participate?

There's no reason to. If these people don't contribute and don't vote -
so what? There's no limited pool of votes that needs to be distributed,
and as I said before, the reason for getting a vote is not passing
some kind of representation quota. If the person contributes
substantially, they should have a vote, regardless of how many or few
inactive voters are there. If they are not the part of the contributing
team, they are free to voice their opinion, which will be listened to,
but they won't be a part of the binding vote process.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Community vote on RFCs

[Stanislav Malyshev]

Hi!

> Understandably, the RFC voting process needs to be restricted to carefully
> selected people, mostly core developers. But the fact is, this process is a
> bit elitist, and fails to represent the community as a whole. A recent

PHP development is not a representative democracy. There's no
requirement to "represent" anyone, and nobody who doesn't contribute to
PHP development in a specific manner has any claim on a vote. If
somebody wants to voice an opinion, it's always welcome. But let's not
pretend like people who actually maintain PHP core and everybody who
ever used PHP or may be thinking about using it have equal weight here.
If it is "elitist" that's because there's the "elite" (not the word I
would choose but if we must keep with it for a minute) - people who
actually implement and maintain stuff. It doesn't mean they don't have
to listen to others - on the contrary - but there's no obligation not to
be "elitist".

> A project being nothing without its users, it would be nice to know whether
> an important change will make them happy or not.

If we could do that, it'd be awesome. I wouldn't mind using the same
tool to know the stock prices next year. But prediction is hard,
especially about the future. Only thing we can reasonably do is to know
the opinion of a tiny minority of the community, randomly self-selected,
about whether or not they think they will like something without the
experience of actually using it. That's certainly better than nothing,
but I wouldn't exaggerate too much about how much better.

> Therefore, I have in mind to develop (time permitting) an experimental
> tool, external to the PHP wiki, that would replicate the voting options of
> each RFC, but would allow everyone with a GitHub account to vote on the
> same options as the original RFC. While the vote results would not directly

Please feel welcome to. However, I don't think this should have any
official role in any PHP governance process, any more than any other
poll on the internet might. That said, my opinion is hearing other
opinions is rarely harmful and frequently useful, so why not.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] @@Jit Attribute Considerations

[Stanislav Malyshev]

Hi!

> Only the trigger mode 4 (attributes) is actually using @@Jit("tracing") and
> "function". This trigger mode feels like micro-management for developers
> and since it has virtually no spotlight in discussions and blog posts about
> the JIT at the moment, we don't know if it brings benefits.

I think turning JIT off is a valid use case, the rest looks much more
iffy. I am not sure we want to let people tell the engine to JIT certain
functions - are there a lot of cases where the engine wouldn't do it but
it's actually the right thing to do?

Don't see any use for "opcache.jit=attributes".

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Stanislav Malyshev]

Hi!

> I know we've voted twice on this already, but are we really sure that 
> the @@ syntax is a good idea?

I think it's not a very good idea, and <<>> was just fine, but a lot of
folks apparently voted for it. Would be nice to see their opinion and
how they answer your concerns. I'm not sure it's proper to override the
vote unless there are some severe technical concerns that make that
choice impossible.

-- 
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Re: Including "Disable the ability to use concrete types in PHAR metadata" in PHP 8.0?

[Stanislav Malyshev]

Hi!

> https://bugs.php.net/bug.php?id=76774 has been open since 2018-08-21.
> 
> That ticket proposes the following:
> 
>> I propose that we disable the ability to have concrete types included in the 
>> serialized metadata by
>> providing an empty classlist to the unserialize call in the PHAR package.
>> This will support the real cases we see in the wild of metadata usage which 
>> is only array key values.

I think it's a good idea. I am a little bit worried that somebody
somewhere may be using phars with object data, and it'd be nice to
create some way for such people to still use these phars, but by default
I think no complex objects is a good idea.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Improving output of syntax errors

[Stanislav Malyshev]

Hi!

> For more examples, see:
> https://rwec.co.uk/x/php-parse-errors/comparison.html
> 
> The patch can be reviewed at: https://github.com/php/php-src/pull/5722

I think this is great, thanks for implementing it!

> I am happy to post a small RFC if people think this requires a vote.
> 
> Any other feedback is welcome.

I personally don't think it requires a vote, as error messages are an
implementation detail and nobody should ever rely on it. Let's wait for
a bit though if somebody argues that it needs an RFC, but otherwise I
think we can merge it.

> (As an aside, the other commonly requested change was to include column
> numbers; this appears to be feasible, but definitely more complex, and
> with potential performance trade-offs. I hope to re-visit this later.)

Column numbers would be awesome too.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Stanislav Malyshev]

Hi!

> Better error messages are obviously better than just replacing the name of
> the token, however this argument is saying that because this isn't perfect
> let's do nothing.

I don't think this is the argument. I think the argument is rather than
half-fix the problem wrong way, let's fully fix it the right way.

> I find it highly frustrating, and borderline offensive, that we are being
> asked to go from a simple, non BC breaking, easy to enact change, to a
> semi-major overhaul of how error messages should look like. I personally

I am not sure why is this "offensive" to you. Is there something in
overhauling error messages that goes against your principles or
religious beliefs? Sometimes overhauling is exactly what is the right
way to go, and not showing internal parser tokens seems to be quite
reasonable idea. If this idea is somehow "offensive" to you, I feel
sorry for you but it's not a reason to abandon this idea. It is also
quite a common things - many proposals in PHP have been rejected because
the community thought it's not the right way to approach things, I
myself have had some proposals rejected because of this. There's no
reason to feel offended by that.

> My perception is that most of the community finds it baffling why anyone
> would be against this change.

My perception is that most of the community couldn't care less for how
the tokens are named, and really shouldn't. It's an internal thing and
should stay this way. If they made to care, that's our fault and we
should fix it.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

[Stanislav Malyshev]

Hi!

> Last, regarding neutrality.  This proposal is literally aimed at adopting
> more-neutral language.  It's not a partisan move to say that harmful
> language should be avoided.

It is a decidedly political claim that long-time industry standard term
with established neutral meaning is suddenly "harmful". And I really
resent the implication of "the color of our skin means you don't get to
have an opinion on this topic" that was made here.

That said, I personally am not going to read any messages on this topic
for a while because I have enough negative emotions lately in my life
without this.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

[Stanislav Malyshev]

Hi!

> I was surprised by the many negative responses: Partly just discussing
> the term "blacklist" that is perhaps not the main issue. Or telling
> people how they should feel and understand words.

Nobody tells you how to feel. But when you claim your supposed feelings
are the reason to censor other's speech then others have the right to
object. I am not sure why this surprises you.

> I think the same applies to this topic

OK, so far for the 25 years of PHP existence I have never heard of a
person who was personally hurt by the use of term "blacklist". I've
heard lots of things said about PHP, good or bad, but today is the first
time I hear about this. So I am not sure we understand the term
"listening" in the same way.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

[Stanislav Malyshev]

Hi!

> It is now highly likely that M$ will force changes to these in github
> which is probably part of what has prompted the thread. Once 'new

If and when this will happen, we'll see the official message from
Microsoft/Github and decide how to act. There's no point in discussing
such hypotheticals now, since right now Microsoft/Github does not
require anything like that from anybody.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

[Stanislav Malyshev]

Hi!

> I think the time has come for the PHP internals to discuss the use of 
> master/slave and blacklist terminologies.
> As everyone can see, we are going through times of change in the world, see 
> #blackLivesMatter for example.

While your quest for more just and fair world is noble and laudable, I
think your energies are misplaced in this case. Terms like "blacklist"
are established industry terms (and are used also outside the industry -
there's a TV show which is called literally "The Blacklist") and have
absolutely nothing to do with race or any other human traits. Objecting
to "blacklist" makes as much sense as objecting to terms such as
"whitespace", "blackout", "white paper", "red-black tree", "rainbow
tables", or declaring the keyword "final" to be anti-Semitic because
there was "final solution". I think there is many other ways to more
productively spend your time than inventing reasons why innocent words
suddenly have nefarious meanings. However, you are, as literally anybody
is, with no regard to any political labels, free to submit a pull
request against PHP source and we will take a look at it then.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

[Stanislav Malyshev]

Hi!

> The moment we change blacklist to blocklist, we are essentially
> agreeing to the fact that we should censor words because they contain
> a color in its name, something that is totally unrelated to any human
> race. Are we also gonna change the internal values of the Garbage
> Collector for PHP to not use different color markings or what about
> the IMG_BLACKMAN filter, are we gonna rename that even though it is
> named so after the Blackman-Turkey transformation? Of course we should
> not. We cannot go around and censor words that have no correlation to
> the current political events occurring world wide. This here is just
> an example of changing things for the sake of changing.

Very well said. Thank you.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV][RFC] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Stanislav Malyshev]

Hi!

>> a) Character count (at line 456, character 23)
>>
>> b) Quote either the remainder or the parsed section on the line (MySQL
>> quotes the remainder, for example)
>>
>> c) Quote the whole line with an indicator where the error occurred. I'm
>> not sure what the best way to do this would be - generically this could
>> be encapsulated in several values: The line content, token start
>> character count, token length / end character count
>>
> 
> I really like the combination of A + C. After using php for 13 years the

If we could do the same as, for example, clang does: just display some
indication where the problem happened within the code, with the line
that caused it. Certainly not displaying internal token names, unless I
am debugging the parser they are useless.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] GitHub FPM label

[Stanislav Malyshev]

Hi!

> Please could someone add an FPM label to github. FPM is a bit on its own
> and the FPM PR's are usually quite independent from other PR's so I think
> it would make sense. Mainly it would help me with filtering and keeping
> track of FPM PR's.

Done: https://github.com/php/php-src/labels/FPM


-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] OSI approval for PHP 3.01 license

[Stanislav Malyshev]

Hi!

> Would someone mind responding to the original poster on the general
> mailing list to let them know that their legal department can rest
> assured that the PHP license is OSI-approved.
> 
> The OSI website might not be up-to-date yet, so you can point them to
> the following mailing list link as evidence of OSI approval:
> http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-May/004841.html

Thanks for following up with this. Bureaucracy is not fun, but sometimes
needs to be taken care of.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] A Standard PHAR library included with PHP?

[Stanislav Malyshev]

Hi!

> One of the primary reasons for many of us — or at least me — to want 
> more things in core is not listed above, and that reason is:
> 
> - Standardization

Core and standardization are completely different things. There are a
lot of things in PHP that are being standardized out of core, and
putting something into core just for standardization is the wrong place
to do it.

To me, this feature clearly looks at something that belongs to
userspace, and magic that it introduces looks like it shouldn't be in
core but in some kind of module, or even better, IDE. Putting sematic
features like deprecation into runtime is not right, if deprecated code
got into runtime, putting out a warning each time it is run is useless.
If nobody looked at these warnings before they got to production, surely
nobody will look at them after.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Function pipe operator

[Stanislav Malyshev]

Hi!

> https://wiki.php.net/rfc/pipe-operator-v2

Just a small pedantry note - in a comparison section, the RFC compares
this syntax to function composition. But this is not function
composition. This is a syntax sugar for calling two functions one after
another, not operator that produces a function. It sounds pedantic but
it's rather important distinction - if |> is composition, than $foo |>
$bar is a new callable provided $foo and $bar are callable (but no
function is actually being called here!). If |> is call syntax, it's
actually the result of calling $bar($foo).

So comparing it to function composition is a bit confusing. Otherwise it
looks OK to me, except the syntax for calling functions and methods is a
bit awkward, but it's not the problem of this RFC I imagine.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [DISCUSSION] Match expression

[Stanislav Malyshev]

Hi!

> I'm not quite sure what the way forward regarding that is. I can understand
> the reluctance to propose the Rust-style block expression syntax, given its

Speaking of which, what is the problem with that? I mean, if we just
declare that the value of a block is the return of the last expression,
would it break anything? Of course, by itself it'd be useless since we
still aren't using blocks as expressions. But if we then had constructs
that could accept both blocks and expressions - and we don't need to
make everything that accepts expressions to accept blocks - we just need
to make it make sense in those "dual" constructs.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Resurrecting named parameters

[Stanislav Malyshev]

Hi!

> 2. Throw a notice if a parameter name is changed. While LSP violations are
> normally fatal errors (in PHP 8), we could use a lower-severity diagnostic
> for this case, that allows code to still run, but makes developers aware of
> the problem. (It should be noted that automatic fixup of parameter names
> using tooling should be fairly easy to implement.)

I think we should have a notice for now, and eventually when people are
used to it upgrade it to an error.

> The larger problem is that internal functions don't have a well-defined
> concept of parameter default value. Parameter defaults are implicit in C
> code, and sometimes based on argument count checks. When named parameters
> are involved, one generally cannot assume that if a later (optional)
> parameter is passed, all earlier (optional) parameters are passed as well.

IIRC I did some work on that when making the skipped parameter RFC, but
I think we have no choice but to make all internal functions we control
have proper default implementation. Older modules may be lagging though,
so another option would be to add some kind of flag to internal
functions that would block named parameters if not set, and make
extension writers fix their functions and then set this flag explicitly.
Of course we'll set this flag for all functions in core, after fixing
those of them that need fixing. Maybe not a flag but using different
macro/API function, etc. - the idea is that some explicit change would
be needed. Yes, that means additional work...

More complicated but milder option would be to only check the flag if
there's a "gap" in parameters - but this may have higher learning curve
as extension writers wouldn't even know their extension needs work until
someone skips a parameter.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Non-capturing catches

[Stanislav Malyshev]

Hi!

On 4/7/20 6:17 AM, Max Semenik wrote:
> Hiya, I'd like to present a new RFC for your consideration:
> https://wiki.php.net/rfc/non-capturing_catches
> 
> Briefly, I want to be able to do the following:
> 
> try {
> foo();
> catch (SomeExceptionClass) {
> bar();
> }

Looks good to me.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] switch expression

[Stanislav Malyshev]

Hi!

> 1. It uses the same AST, code generation and opcodes as the switch, I
> don't agree that it is significantly different than the switch that we
> already have.

This is reasoning in wrong direction. Nobody cares which opcode it uses.
It is significantly different *for the user*, the fact that it may
compile into same opcode means nothing to the user.

> 2. Adding the `match` keyword is a breaking change, not an insignificant one.

I thought with AST we should be past banning keywords as function etc.
names, aren't we?

> 3. If we can fix the switch statement semantics in the future the two
> will only differ in that one returns a value and the other one
> doesn't. This is a much smaller distinction than functions/closure.

We don't need to "fix" anything in the existing switch, and likely
couldn't because of immense BC breakage it would cause. If you want
different switch, you better start with different keyword.

> 4. If we'd every want to add pattern matching, we'd still have a
> keyword available to us.

What you proposing essentially *is* pattern matching, just very limited
one. Extending it would be a natural development.

> type coercion. This would make it a replacement of the switch
> statement instead of an addition.

I don't think we need replacement for switch statement. Adding simple
matching expression seems to be a good idea, but please don't let it get
out of the way and turn into something that is too complex and
controversial and be buried under details that nobody actually needs.
It's better to have sometime simple.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] switch expression

[Stanislav Malyshev]

Hi!

> My recommendation would be to just borrow Rust's keyword:
> 
> $result = match ($var) {
>   $expression => $expression;
>   $expression => $expression;
>   $expression => $expression;
>   default => $expression;
> }

Yes, this would be much better idea.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] switch expression

[Stanislav Malyshev]

Hi!

>> I'm still not sure why if we're calling it "switch"
> 
> C# does it. Not to say everything they do is right but it's reassuring
> that a big company like Microsoft had the same approach.

No it isn't. Having two syntaxes for one keyword is not a good idea,
whether Microsoft is doing it or not. I understand why they did it, but
it's still not a good idea.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] switch expression

[Stanislav Malyshev]

Hi!

> You can take a look at the tests to get a feel for what it’s like:
> 
> https://github.com/php/php-src/pull/5308/files
> 
> Multiple conditions are possible:
> 
> ```
> 
> return $day switch {
> 
>     1, 7 => false,
> 
>     2, 3, 4, 5, 6 => true,
> 
> };

I'm still not sure why if we're calling it "switch" it can't use
traditional switch structure. If it uses something else, it must be
called by some other keyword, it's not a good idea to have two "switch"
constructs in the language with completely different syntax.


-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [VOTE] Userspace operator overloading

[Stanislav Malyshev]

Hi!

> I think “as long as it is not overused” are the key words there. We have
> a very limited number of internal classes with operator overloading

I think the whole point of leaving it to extensions was ensuring it's
not overused. And now I see people arguing "well, if it's available to
extensions, then it also must be available to userspace" - which is the
reverse of the premise under which it was implemented in the first
place. Once we open this door, there's nothing that would prevent
overuse and abuse - in fact, as we see, even having this door closed
leads people to think since it exists, it must be used to the maximum,
addition of userspace operator overloading will surely be taken as
encouragement to be as creative as possible with overloading operators
and inventing all kinds of incomprehensible and inconsistent operator
schemes because it looked cool at the moment. So if anybody has hope it
would "not be overused" - it will be.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Constructor Property Promotion

[Stanislav Malyshev]

Hi!

> I would like to submit the following RFC for your consideration:
> https://wiki.php.net/rfc/constructor_promotion

I like this shortcut. I am not sure though I understand why callable is
not allowed? Can't it just create a non-typed property?

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] semicolon terminator for switch cases

[Stanislav Malyshev]

Hi!

On 3/26/20 1:26 PM, David Rodrigues wrote:
> I agree with Tovilo. It is weird and confusing. Actually I never know
> that it was possible. 

You seem to contradict yourself - if you never knew it was possible, how
could you ever be confused by it?

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] semicolon terminator for switch cases

[Stanislav Malyshev]

Hi!

> Maybe something to deprecate in PHP 8.0.
> https://wiki.php.net/rfc/deprecations_php_8_0

Why? Whose life it'd make easier?

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Class cast

[Stanislav Malyshev]

Hi!

> Actually it is a simplest case, where only a single information was
> considered. But you can expand it to something more complex, where
> currently you will need create a static method to copy the data, which
> is not a normalized way like cast could do.

You can always use anonymous functions if callable is needed.

> 
> Or you can increase the type of information when possible. For instance:
> 
> function requiresB(B $b);
> 
> But you have only A $a.
> 
> You can create:
> 
> function __cast($value) {
>     if ($value instanceof A) return B($value, 123, M_PI);
> }

That's not a cast. That's creating new object from another object.
Things like this should be an explicit call. Otherwise the meaning of
this code is unclear - it pretends that you just change the type, but in
fact it's a completely new object which can be entirely unrelated to the
old one. Things like that should be explicit.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Class cast

[Stanislav Malyshev]

Hi!

> 1. Converting from A to B:
> 
> $a = 123;
> $b = (Number) $a; // $b is now instanceof Number
> 
> A instanceof Number will created based on $a value.

What's wrong with new Number(123)?

> 2. Reduce object type (I don't know the technical term):
> 
> class A {}
> class B extends A {}
> 
> $b = new B;
> $a = (A) $b;
> 
> $a still is $b, but with "limited" access to A methods and properties.

Not sure why would you want to do this? What's the use case?
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

[Stanislav Malyshev]

Hi!

> Well a significant part of the purpose of the RFC is to make the case
> for why it *should* be done, and the benefits in doing so, and only to

And the necessity of making the case also assumes it may, despite all
the effort, fail. The community members may remain unconvinced the
change that is proposed is beneficial. This is, ultimately, always the
reason to vote no.

> To vote yes is to state your overall agreement with the arguments made
> in the RFC. If you've read up and want to vote "no", I think that is
> perfectly fine and should be fully encouraged, but do the decent thing
> for your fellow developers and explain why so they're not left trying to
> guess.

As I noted, the default reason is always "the author of the RFC failed
to convince this change is necessary or beneficial". If somebody tries
to sell you something, you may have some specific flaws to point out and
may be even be fixed, or you may not be interested in the idea at all.
In the latter case, it's also OK to say you aren't interested and in
general case, you don't owe any improvement suggestions or detailed
explanations about that. The proof of need - especially for a mature
software like PHP - is always on the proposer.

> 
> Ultimately, how can an RFC ever be improved to be more widely acceptable
> if the people voting in the negative don't give feedback?

Sometimes - not always, but sometimes - the best improvement to the idea
is just not doing it. It's a valid outcome too. In the process of making
new things, everybody is bound to have a bad idea once or twice. It's
completely normal and once it is discovered it's a bad idea, there's no
problem in discarding it and moving on.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

[Stanislav Malyshev]

Hi!

> If a person doesn't have the time or inclination to read into the
> details of an RFC, and also doesn't have time or inclination to engage
> in discussion about it, and also doesn't have the time or inclination to
> give even the briefest of justification about why they are casting their
> vote a particular way to help inform future discussion...
> 
> Well, they shouldn't be casting a vote in the first place.

And how you intend to ensure that? You can't ask for a graded 500-word
essay proving the voters understand the issues. If somebody wants to
vote "no" or "yes" without reading, asking for reasons won't help.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

[Stanislav Malyshev]

Hi!

> Would it be possible to add a feature when voting were people either
> need to type in a one to two sentence reason why they voted "no" on a
> proposal OR select from the reasons that others have already given
> when voting down the specific RFC?

As an optional feature, it might be helpful. But it shouldn't be mandatory.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Argument with default value

[Stanislav Malyshev]

Hi!

> As it's arisen on the list again, I've written a note detailing my
> view of the previous discussion:
> 
> https://github.com/Danack/RfcCodex/blob/master/explicit_defaults.md

As the author of that RFC, I am not particularly sure how it can be
"improved", as main argument from what I understood has been pretty much
"we should do named arguments instead" and as we can all see that isn't
happening either. And I don't have time or energy to go through another
fight on this. But if somebody wants to, I could possibly help with
technical details if necessary (whatever I remember from 5 years ago).

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Make sorting stable

[Stanislav Malyshev]

Hi!

> Given that we have internal classes which deliberately have such
> comparison behavior (i.e. returning 0 or 1, to signal that there is no
> order defined), e.g. Closures[1], I tend to prefer raising a warning
> instead of trying to recover.

I think there weirdness is because equality and comparison are mixed.
Equality can be defined for almost every object, but comaprison makes
sense for much smaller set of objects. So I wonder maybe a good solution
would be to somehow separate the two. And then maybe raise an exception
when trying to compare objects that can't be compared?

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] OSI approval for PHP 3.01 license

[Stanislav Malyshev]

Hi!

> Bump. Anyone?
> 
> If there are no objections, can someone go ahead and merge this?

I merged it.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] OSI approval for PHP 3.01 license

[Stanislav Malyshev]

Hi!

>>> If this version is approved, will the steward voluntarily deprecate version 
>>> 3.0, and if not, and if 3.01 is approved, should 3.0 be involuntarily 
>>> deprecated?
> 
> 
> The “steward” is the PHP Group. I know that Rasmus, Zeev, and Sascha are 
> still active on this list, but I don’t know what the protocol is for making 
> this decision. Would this need a simple RFC for the internals community to 
> vote on? If that’s the route, I’m happy to put together a draft.

I think it is already effectively "deprecated", as all current PHP
versions use 3.01.  There was no formal announcement about it, I think,
but since this is the license that is used only for PHP engine and not
much else (and HHVM, which also uses 3.01) there wasn't much point about
explicitly stating it, but if it's necessary, I guess it'd make sense to
"deprecate" it, whatever that means.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Re: OSI approval for PHP 3.01 license

[Stanislav Malyshev]

Hi!

> Does anyone here remember why the changes to the license where done in
> the first place? The commit was done on the 1st of Jan. 2006 (at least

Probably for more clear wording (since outside of context "PHP" can mean
many things).

Since 3.0 and 3.01 are essentially the same license, I'm not sure who
would bother to go through the bureaucracy, not sure who did it the last
time (or whether anybody did that at all). Maybe worth reaching out to
OSI folks and asking them to update their list, since 3.0 and 3.01 are
the same.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Support rewinding of generators

[Stanislav Malyshev]

Hi!

> There is a relatively simple (at least conceptually) way to make generators
> rewindable: Remember the original arguments of the function, and basically
> "re-invoke" it on rewind().

That is provided that:
1. The original arguments of the function can be "remembered" - those
can be complex object with a lot of state, not always visible to PHP,
preserving which may be impossible.
2. The generator function is pure and does not have side effects - or at
least side effects of rewinding are expected and desirable.

It also means that we'd have to always preserve the arguments of the
generator function in the state they were when it was called or at least
try to - not sure what performance impact this implies. That or
explicitly declare the generator rewindable with the implication that
once we declare that we shouldn't pass any arguments to it that can't be
or shouldn't be preserved.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Userspace operator overloading

[Stanislav Malyshev]

Hi!

> - The individual symbolic operators, with no intrinsic meaning - e.g.
> overloading . for concatenation on strings but dot-product for
> vectors; or a DSL overloading << and >> for "into" and "out of".

Please no. I know it looks fancy and some languages love it, but for a
person not in on the joke reading such code is a nightmare - it's
basically gibberish until you learn all the types and which meaning each
of the types assigns to operators. I mean, I could be maybe talked into
having users overload "+" to mean "add some kind of objects that are
like numbers but not actually integers" because my intuition still works
there even if I don't know the exact type. But if someone thinks it's
super-cool to override + to make it add element to the cache object -
please no. It's way worse than just using plain old ->addObject(). You
may save couple of keystrokes and make your code completely
incomprehensible for people who come after you.

I know DSLs have its niche but I seriously doubt average PHP user
implements a lot of DSLs that are required to work natively on PHP engine.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] deprecate md5_file and sha1_file

[Stanislav Malyshev]

Hi!

> the hash_file() function still supports md5 and sha1 so people that need it
> should then migrate to hash_file('md5', ...) or hash_file('sha1', ...)
> instead. That was the idea

This means spending time and effort to cause extra work to people that
already have working code with existing PHP and don't need our "help". I
don't think we should be doing that.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] deprecate md5_file and sha1_file

[Stanislav Malyshev]

Hi!

> I suggest to deprecated the functions md5_file() and sha1_file(). This will

Not sure what's the point of it. SHA1 and MD5 didn't change. The
recommendations for their usage has changed, but we generally don't use
deprecation warnings to improve users' code and recommend them how to
structure their code better. Deprecation is usually for functions that
are unsupported (and going to go away) or not having any non-broken uses
anymore. We have crc32() function which is much less secure than md5 for
check-summing obviously, and we don't deprecate it because of that. I
don't think we should use deprecations for that purpose.

> Carrying around these two dedicated functions seems a bit too much for a
> modern PHP. What do you think?

There's zero effort expended on "carrying around" these functions, and I
don't see why it's "too much" for "modern PHP"? What changed in "modern
PHP" that suddenly brought forward the need to minimize the number of
existing functions? I don't see any reason for that.
On the contrary, deprecating it causes work for people that legitimately
use these functions, and makes them either turn off deprecation warnings
(unsafe and may lead to real deprecations pass unnoticed) or work around
this. I don't think it is beneficial.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Planning an RFC to allow calls to global functions in constant expressions

[Stanislav Malyshev]

Hi!

> The constant expressions will be evaluated at the same time php currently 
> evaluates constant
> expressions.

But you essentially propose running arbitrary code at that time, which
is much bigger deal than evaluating simple constant expressions. While
simple functions like strlen() would probably be OK, running arbitrary
function means possibility for arbitrary side effects, which makes the
whole thing completely unpredictable.

> Another problem with using define() is that opcache cannot optimize global 
> constants,

opcache can't also optimize runtime-evaluated constants, because results
and side-effects of an arbitrary function call is not guaranteed to be
the same. It could only optimize anything if it were guaranteed that the
function is pure, does not depend on anything but its arguments and has
no side effects.

> because define() will emit a notice instead of raising an Error if the 
> constant already exists.

You can trivially check for this, and if it ever would be a problem,
define() error level can be changed, but I don't think it's a real issue
since it was never changed so far.

> So the performance is slightly worse.

If you try to optimize performance this way, you're optimizing
performance in a wrong way. No sane code would depend on performance of
define().
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] Planning an RFC to allow calls to global functions in constant expressions

[Stanislav Malyshev]

Hi!

> For example, allow `\count()`, `\strlen()`, `\array_merge()`, and 
> `\in_array()`,
> but don't allow functions such as
> `\strtolower()` (different in Turkish locale),

What happens if a function like strlen() is applied to a non-string
argument? Conversion to string is certainly runtime-dependent even for
primitive types like floats.

> allow calls to all global functions

Not sure I understand here - when these calls will be happening? And if
you need a value that depends on runtime calculation, what's wrong with
using define()?

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Allow ::class on objects

[Stanislav Malyshev]

Hi!

> If it could return `string`, that'd be super useful!

Would it? There's no class "string". So for all purposes other than
printing out, that would be a pretty big footgun.

> We have tons of lines of code that look like: is_object($foo) ?
> get_class($foo) : gettype($foo)
> Getting rid of them would be very sweet !

It could be useful to have generic function for describing objects, but
that's not what ::class should be doing. It should not return things
which aren't classes.

-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] What to do with "$array[foobar]"?

[Stanislav Malyshev]

Hi!

> I think there's two ways to address this. One is to deprecate and
> eventually remove the non-wrapped array interpolation syntax entirely,
> requiring people to use the generic "{$array['foobar']}" syntax instead.
> For the sake of consistency, I think this would also include deprecating
> the "$array[0]" variant.

The first part seems to make sense but I don't think losing "$array[0]"
does... I get the consistency argument but I feel most people would
rather have this useful syntax working and not worry about the fact that
it's theoretically "inconsistent". Consistency only helps when it allows
to make useful inferences, something not working is rarely useful
inference.

> The other is to add support for "$array['foobar']" and
> "$array[some(complex(expression()))]" in general, and only deprecate the
> "$array[foobar]" syntax.

This also seems an acceptable option, if we can make stuff inside []
behave reasonably. We probably don't actually need anything really
complex - if one wants complex stuff, {} syntax should be used. I think
primary target here should be simple stuff like numbers and strings
work, all the rest is optional.

-- 
Stas Malyshev
smalys...@gmail.com

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