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

[Brady Wetherington via internals]

> > That's 1.5 million hours, which is 171 developer-years.
>
> If we're going to imagine numbers; there are 6 million PHP developers
> in the world*. If on average they each lose just 1 hour per year by
> making typos and accidentally creating a properties dynamically,
> that's 6 million hours, or 684.93 years!
>
> So the value delivered by this change would be 4 times the cost just
> in the first year. And then every year after that it's pure benefit.

And as many of those who wish to, can opt-in to the attribute/feature
can save themselves that time (and probably should!). We probably will
for our code, tbh! But forcing this issue is going to be massively
destructive to the ecosystem. Not everything is brand-spanking new.
Some things just work well and don't get updated that often.

> > What I'm scared about is about our 42 dependencies in composer.json,
>
> How about sponsoring each of your dependencies some money, to
> encourage them to check if their code is compatible after this change,
> and fix it if it isn't.

You are trying to solve a technological problem with an economic
solution. And one that requires that the entire ocean be boiled before
it is solved. We already do give money to several places, and would
like to give more. And we will. But that's not going to fix this,
unless everyone does. And not everyone will. We happen to make money;
not a lot of other projects do.

We ourselves are open source. We don't get more than a handful of
donations per year. This doesn't seem to be the right way to solve
this problem.

> If a dependency is used by even just 1000 companies, and each of those
> companies chips in $50, then $50,000 will fund many months of work on
> that dependency.
>
> Most open source is done by people in their free time. Because
> companies keep refusing to fund open source.
>
> > might be stuck on a framework or something that's no longer being updated,
>
> Having companies sponsor open source projects makes it less likely
> they will be abandoned.

Maybe, but not always. Sometimes people just lose interest. But again,
you're proposing to potentially break a big chunk of packages in hopes
that an economic model that has not successfully worked anywhere else
is going to work here. That seems cavalier.

Right now, to get a collection of packages that work between php 7.4
and 8.0, we've had to spend tremendous amounts of work just to get
there - and we had to pull 7.3 support in the process. I didn't want
to do that; I want our software to be available to as many people as
possible - not everyone has the freedom to install their own version
of PHP - some are on crappy shared hosting or have to deal with some
creaky IT department. Every single backwards-incompatible change
shrinks our version-sandwich down further, especially in the context
of packages. Again, I can add the new attributes to our own software
today, and that means we're OK - but I can't speak to every single
package we're dependent on or *they* are dependent on.

-B.

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

Re: [PHP-DEV] Need Update regarding PHP Travis CI Execution

[Pierre Joye]

Hi Nikita,

On Thu, Nov 25, 2021 at 3:47 PM Nikita Popov  wrote:

> Travis is working again.

In the meantime, I asked AWS if it is ok to share GD's graviton box
with php, all good.

If we don't have one, happy to add you there. GH Actions already in
place, only need to set up two accounts (I never did but should be
smooth :).

best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

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

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

[Dan Ackroyd]

On Fri, 26 Nov 2021 at 00:55, Brady Wetherington via internals
 wrote:
>
> That's 1.5 million hours, which is 171 developer-years.

If we're going to imagine numbers; there are 6 million PHP developers
in the world*. If on average they each lose just 1 hour per year by
making typos and accidentally creating a properties dynamically,
that's 6 million hours, or 684.93 years!

So the value delivered by this change would be 4 times the cost just
in the first year. And then every year after that it's pure benefit.

> What I'm scared about is about our 42 dependencies in composer.json,

How about sponsoring each of your dependencies some money, to
encourage them to check if their code is compatible after this change,
and fix it if it isn't.

If a dependency is used by even just 1000 companies, and each of those
companies chips in $50, then $50,000 will fund many months of work on
that dependency.

> probably more, if we try to include work-life balance and whatnot :P

Most open source is done by people in their free time. Because
companies keep refusing to fund open source.

> might be stuck on a framework or something that's no longer being updated,

Having companies sponsor open source projects makes it less likely
they will be abandoned.

cheers
Dan
Ack

* https://www.theregister.com/2021/04/26/report_developers_slashdata/

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

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

[Brady Wetherington via internals]

> This is a little bit overly dramatic. This isn't such a huge change that 
> would affect 50% of existing projects. It's likely to affect a small number 
> of projects in a very limited way.
> It's also not true that developers will slap #[AllowDynamicProperties] on 
> every class. That would imply that every class in their project is using 
> dynamic properties. That would be absurd. If it's truly the case that every 
> class in 50% of the projects uses dynamic properties then we should not 
> consider this RFC at all. The whole premise of it is that it's highly 
> unlikely that many people are using dynamic properties on purpose. It's true 
> that many old unmaintained projects might use it as a feature, but the 
> keyword is "unmaintained". I would not trust dependencies that haven't been 
> kept up to date for a few years.
>
> I doubt that having to add a single attribute to a selected few classes would 
> be such a major issue that projects would decide to stay on PHP 8.1 rather 
> than upgrade. It's not comparable to Python 2/3 situation IMHO.
>
> I would be interested to know some numbers from Snipe-IT. Have you done a 
> preliminary analysis of your codebase of how many classes are actually using 
> dynamic properties? From a brief look, I can see that usually most properties 
> are declared.

Sorry, I didn't mean to sound dramatic, just trying to share my concerns.

I suspect that you're very right, and *very very few* projects use
dynamic properties on purpose (in our own code, we probably don't ever
_mean_ to, except maybe for our Custom Fields feature, but we could do
the attribute for that one or so class(es)), but that's not my point.
I suspect many of our _dependencies_ might be using it (by accident,
to your point!). But I can't control every package in my
composer.json, which is where I'm worried. I can't force those
developers to do what I want, and I don't want to be stuck in a
'version sandwich' because I'm waiting for one of them to change
something. And maybe when they *do* try and change something, they
might also change the interface (a violation of semver, but, it
happens in the wild, more often than we would like). We have to
support old and new versions of php and that can make our Composer
situation a real nightmare (I just dragged us forward to be able to
work in PHPv8, and it was far harder than it needed to be).

I'm not worried about our code at **all** - we write it! We can change
it (and we'd be good citizens, I promise, we would!) And that
attribute is ignored on versions of PHP that don't support it; which'd
be fine for us. That's a fair ask, and we'd do it.

What I'm scared about is about our 42 dependencies in composer.json,
and the ~400k bytes of dependencies described by our composer.lock.

And I'm worried about other projects that have even more dependencies,
or might be stuck on a framework or something that's no longer being
updated, but they can't migrate off of for whatever reason. I wouldn't
wish that on anyone.

Thank you for considering, and for your extremely well-written response,

-B.

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

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

[Kamil Tekiela]

Hi Brady,

This is a little bit overly dramatic. This isn't such a huge change that
would affect 50% of existing projects. It's likely to affect a small number
of projects in a very limited way.
It's also not true that developers will slap #[AllowDynamicProperties] on
every class. That would imply that every class in their project is using
dynamic properties. That would be absurd. If it's truly the case that every
class in 50% of the projects uses dynamic properties then we should not
consider this RFC at all. The whole premise of it is that it's highly
unlikely that many people are using dynamic properties on purpose. It's
true that many old unmaintained projects might use it as a feature, but the
keyword is "unmaintained". I would not trust dependencies that haven't been
kept up to date for a few years.

PHP has had many breaking changes over the years. PHP 8.1 introduced a much
more annoying deprecation: Deprecate passing null to non-nullable arguments
of internal functions. This one I would have no trouble believing that it
impacts 50% or even the majority of PHP projects. Dynamic properties
compared to this should be a piece of cake.

I doubt that having to add a single attribute to a selected few classes
would be such a major issue that projects would decide to stay on PHP 8.1
rather than upgrade. It's not comparable to Python 2/3 situation IMHO.

I would be interested to know some numbers from Snipe-IT. Have you done a
preliminary analysis of your codebase of how many classes are actually
using dynamic properties? From a brief look, I can see that usually most
properties are declared.

Regards,
Kamil

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

[Brady Wetherington via internals]

Sorry for the 11th hour chime-in, but I wanted to add some context
about this proposed change, and how it would likely affect our project
and many others. I know the prospect of opt-in was already addressed,
but I wanted to talk about what our experience would be here. (We make
Snipe-IT, which is open-source but also a paid-for-hosting or
pay-for-support project).

Many modern PHP projects (like ours) have 10's or 100's of
dependencies, often installed via Composer. With this change, many of
those will start to throw deprecation warnings - eventually failing in
PHP v9. Not every package is equally modern, or equally
well-maintained. I suspect there are plenty of newer packages that
will "Just Work™" and that's great! But there are probably many older
packages, or more poorly-maintained ones, that will not.

Packagist has around 3 million packages. Figure half are "not modern"
(needing updates to be compatible with the proposed change) - that'd
be 1.5 million packages. (And that's probably pretty conservative).
Figure it takes an hour, each, to fix them all (again, that's
conservative). That's 1.5 million hours, which is 171 developer-years.
That's effectively 2 or 3 developer lifetimes (probably more, if we
try to include work-life balance and whatnot :P )

And what are 9 out of 10 maintainers going to do? They'll just plaster
#[AllowDynamicProperties] in front of every class, and be done with
it. Voila! Compatibility. So the bulk of those 171 developer-years
will be wasted.

I think opt-in would be a better approach - per-class, certainly
(#[FixedProperties] or #[StaticProperties] maybe?), but maybe per-file
as well, or maybe even in php.ini if we want to go per-project.

Different language front-ends to the php back-end engine could
certainly by default jam the attribute in on every class; that'd be
fine. But for PHP itself, one of its massive selling points has been
that it tries very hard not to break compatibility - I have written
code for PHP v4 that I have been able to drag up to PHP v7.x without
too much work. I'd hate to lose that, or make it much harder -
especially for dependencies that I don't have direct control over.

By no means am I suggesting that PHP is a 'dead language' - but let's
not cram ourselves into a Python2/Python3 compatibility hole where we
make upgrades into a nightmare for people. Adding types for variables
and parameters has been optional and is gradually becoming the
standard thing to do; I'm sure this would end up the same.

Anyways, hoping to just add some more context for those who are voting
on the proposal. Feel free to ask any questions you'd like and I'll be
happy to answer as best I can.

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

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

[Tim Starling]

On 25/11/21 11:34 pm, Paul Crovella wrote:
> On Thu, Nov 25, 2021 at 3:14 AM Tim Starling  wrote:
>> On 25/11/21 7:57 pm, Côme Chilliet wrote:
>>
>>> To reuse the example from the RFC, if I want to convert a UTF string to 
>>> uppercase using Turkish rules and get dotted capital I, what should I use?
>> For case-insensitive comparison you can use Collator. But for display
>> you just have to do it yourself. For the Turkish Wikipedia and other
>> Turkic language websites we are currently using str_replace().
> Any particular reason not to use transliterators? https://3v4l.org/I038T

Thanks, I missed that.

You would need to do your own mapping from language code to
transliterator name, since it only has converters for az/tr, el, lt
and "Any", with no fallbacks. For example if you did
Transliterator::create("en-Upper")->transliterate('a') you would get a
fatal error.

Presumably if I submitted a PR adding wrappers for u_strToUpper()
etc., it would not be rejected on the basis that we already have
transliterators.

-- Tim Starling

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

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

[Dan Ackroyd]

Hi Juliette,

On Mon, 15 Nov 2021 at 23:36,  wrote:
>
> I've been asked to post the link to the Twitter discussion in this
> thread for visibility.
>
> The Twitter thread generated, and is still generating, quite a lot of
> discussion,

I'm not going to quote from the Twitter thread partly as lot of that
discussion isn't that pleasant. To be clear, this change isn't being
proposed to annoy open source maintainers, it's proposed because
people think it will make the language better, to a great enough value
to be worth the BC break.

But also, a lot of that thread is about the experience of being an
open source developer is absolutely terrible due to many factors
including:

* an almost complete refusal of companies to sponsor work.

* people who work for companies that use open source having an
attitude of entitlement to 'gold level support', and will very quickly
start using emotionally manipulative language e.g. "if you cared about
this project you'd work harder on it".

* a lack of new contributors to open source.

I completely understand how all of things are pretty aggravating.

It's particularly galling when a maintainer tries to get some funding,
e.g. by holding back a release targetting a new version of PHP, other
people will undermine that effort by forking the library and doing
just enough to get it working, but not committing to do any future
work.

I'm in the lucky position that because PECL is so hard to use (and
gate-keepered as to who can use it), that I was able to hold off doing
the release of Imagick with PHP 8.0 support until a couple of
companies stepped up with a (greatly appreciated) non-trivial amount
of sponsorship.

What the future holds for open source is unclear to me. And it's not
at all obvious that open source isn't a morally wrong thing to do, as
to a large extent it seems to rely on individuals subsidising for
profit companies.

However I don't think that slowing down the improvements in PHP core
itself is an appropriate response to companies refusing to pay to
support the projects they rely as a business on.

I do recommend anyone who has an open source project to:

* make sure you have github sponsors or other sponsoring services setup.

* ask for payment for work done previously. If you've created a
library that companies are dependent on, it's okay to refuse to work
on it until there is a decent amount of support for that work done.
You don't have to commit to doing new work until the project has a
sustainable rate of sponsorship.

* compare the amount of money you're getting for a project to the
commercial rates for developers, and not to how much cup of coffee is.

* Feel free to forward any cash you don't feel justified keeping to
other opensource projects particularly upstream dependencies or tools.
Or if you don't have enough time to work on that project yourself,
feel free to ask for enough money to pay someone else to work on it.

Once those done, it's perfectly acceptable to put a project on
'strike' until it's funded adequately and refuse to release new
versions to accomodate changes in PHP.

I know that saying 'no' to users is draining as they so often try to
guilt maintainers into doing work for free. If anyone would like me to
help explain to users "your company needs to start sponsoring this
project before this project will acknowledge this issue", in any of
their projects repos, please ping me on twitter
https://twitter.com/MrDanack

cheers
Dan
Ack

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

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

[Dan Ackroyd]

On Fri, 12 Nov 2021 at 19:00, Matthew Weier O'Phinney
 wrote:
>
> Our IDEs, coding standards, and static analysis tools can already flag
> these things for us, helping us catch them early. Hell, unit testing will
> find these for us, when a test fails due to a value not being set in a
> property that we expected.

New users don't have these tools. And a lot of 'experienced'
developers don't have those tools either. A disconcerting number of
developers don't even use source control.

Although exactly which users a language should be designed to cater
for, I don't think an answer of "those who have used it long enough to
setup static analysis tools" is a great one.

But even when people have static analysis tools setup, they are slow to run.

Andreas Heigl wrote:
> So while the static analysis is one possibility, the other
> one is writing appropriate tests.
> .
> So the mistakes-part would be easy to handle.

This is not my experience.

My experience is the same as Matthew Brown wrote:
> I have heard newcomers express literal
> surprise when discovering this for the first time, and not in a delighted
> way.

People encounter the 'feature' of PHP not warning or erroring on
dynamically creating a property by accident most of the time.

They make a typo in their code and wonder why their code isn't working
as expected.

Even though I use an IDE, and have pretty comprehensive static
analysis and tests, this feature keeps biting me often enough that I
created a trait to stop it
(https://github.com/Danack/Params/blob/main/lib/Params/SafeAccess.php)
which I normally copy and paste into each project.

Matthew Weier O'Phinney wrote:
> Making this fundamental change to the language means, however, that a lot
> of things that we were previously able to do that "just worked" now raise a
> deprecation notice, and, later, a compilation error... unless we make a
> change to our already working, fully functional code.

This is the trade-off that all RFCs that have BC breaks have:

1. it's going to cause some work for projects that deliberately use
this feature.

2. it's going to save time/improve the developer experience for people
in the future

If PHP was a dead language that fewer people are starting to learn,
and few new projects are started using it, then option 1 is probably
the side to prioritise. But I'm hoping that PHP isn't a dead language,
and that the future benefit from not having to spend so long debugging
their code is greater than a small amount of BC break.

For the people who are currently voting 'no', I'd ask are you really
sure that the amount of work adding "#[AllowDynamicProperties]" to the
classes you want to keep having dynamic properties is really that much
time compared to the time that would be saved by having PHP itself
give an error when a user accidentally creates a dynamic property?

cheers
Dan
Ack

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

Re: [PHP-DEV] Automatic performance benchmarking: PHP 8.1 is ~30% faster than PHP 7.4

[Matthew Weier O'Phinney]

On Thu, Nov 25, 2021, 12:17 PM Máté Kocsis  wrote:

> Sorry Folks, but I have to provide some update about the results:
>
> Unfortunately, due to a silly bug in my calculator code, the % differences
> in the benchmark results were slightly off from their real values, so I
> have just retroactively adjusted them.
> In fact, the Symfony demo app on PHP 8.1 is ~23% faster than on PHP 7.4,
> while Laravel runs ~21.5% faster on PHP 8.1 than on PHP 7.4. In my opinion,
> this performance increase
> is still very remarkable, so I'm not disappointed at all that the
> improvement is slightly less dramatic than I previously suggested.


Honestly, anything over 10% improvement when it comes to performance,
particularly in a programming language, is significant.  20% can have a
huge impact on production loads!


In any
> case, sorry for the misleading news!
>
> I wish a happy PHP 8.1 release party to everyone:
> Máté
>

[PHP-DEV] PHP 8.1.0 Released!

[Patrick ALLAERT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The PHP development team announces the immediate availability of PHP 8.1.0.
This release marks the latest major release of the PHP language.

PHP 8.1 comes with numerous improvements and new features such as:
- - Enumerations
- - Readonly properties
- - Fibers
- - Pure Intersection Types
- - never return type
- - First-class Callable Syntax
- - "final" modifier for class constants
- - New fsync and fdatasync functions
- - New array_is_list function
- - Explicit Octal numeral notation
- - And much much more...

For source downloads of PHP 8.1.0 please visit our downloads page
(https://www.php.net/downloads.php), Windows source and binaries can be
found on https://windows.php.net/download/.
The list of changes is recorded in the ChangeLog
(https://www.php.net/ChangeLog-8.php#8.1.0).
The migration guide (http://php.net/manual/en/migration81.php) is available
in the PHP Manual.
Please consult it for the detailed list of new features and backward
incompatible changes.

Many thanks to all the contributors and supporters!

Release Manifest here and below:
https://gist.github.com/patrickallaert/0be0058dafafc7a669af7f6d5f39bc81

Patrick Allaert, Ben Ramsey & Joe Watkins

php-8.1.0.tar.bz2
SHA256 hash:
0725ed2baea125496a898455d501a77460218b2a0cfad773fa9322f491b82b61
PGP signature:
- -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmGdObkACgkQGZ+d/vb/
uv2zAhAAh8XwQSAMOM86xbcTScnAyhHSSTtujaCH/vUMOEsdE1a/fc0a0lAwW4T1
/IFF/0+GLpOBq827KtG8DrklNBnnc3wOwGWrBu55timNWuT5vuwFuOqExf2Nrlw3
Pxz1rQ1CbCkEsBr8gF74/Tw5MS8fay+Oq0FXqHPLfL/8/oBBmpPsddR/0ycFB7PP
K1OVnpRwfq3UanVOUxOQxfsR86sGsldNn6y8iv2N2D/Mq8Qxjeu1ZAy34gwytUW3
g0XxcXAYA23KwWuDM9S4zdSTjh5cGCzbt3ueRXC59ar3wNkL8dAQlytlyWT1U8B+
OCCp/Nc94ebNXZFe0TfltMgpepjOYkJw33MzJC3K3EgAeUI4zzgB38CS8ekYExDq
VtTW9edUCt1SBXbsoX910QyU5O4HWA84qc80Jk2Qoiong7IRnotHDsf8pAzDeg3L
MSCxU8syPieMRiS1eYaFXV+DRY8ByiGuOLtMeh00OSMkXGK6QP7x31XKs+SbVli9
Pen4KR4X3mNQ3akAM5qSMiHkzitZXhjtcu9guuwgzinBhJENIEQlKbvmDVAUjWlF
uPdHPby9Ip33sL8ZCRs3YQUofz3DaGbxZqDu801yUzYjWG/f2IXauU7QUkMiZ1yY
rbRoO/YMLy8rz80rOK8tAS3GiyxVn5hR2Fcgsks9za0ZXx8oQA4=
=7J12
- -END PGP SIGNATURE-

php-8.1.0.tar.gz
SHA256 hash:
848705043ea4a6e022246ae12a1bff6afcf5c73ea98c6ac4d2108d6028c5c125
PGP signature:
- -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmGdObkACgkQGZ+d/vb/
uv39wg//Yfy45SiTS/72gTQhZhX0ssSeMHuYh5Uv2GLtb5HrzpYmaJYfUKs5SS3r
Ztik7sV8HclvRfy1wZGv4TkFPrptxjXXSpvrXaLKRb4qqN4XUtD1MpuX11BUrX9S
J2izARb/OK9+NNn1zuQ0gPC3gjdE4RvUP9DOv3DcDktg91itaUWeM4/B4o1RCQlk
H2UPmVE4ZX5QZrAY1TDjuxDpT5N32piLHPR6/oO/iTb5Y9vBLDH0qYVG1wlrwtH4
B2JDLnvN1B1Ta4t4wbR3EgpKkMP4VTAbcnTbM7fm0kHB8at6RZCFbroLoz8BpLGi
oHGPFIDrbswn26Vtgb7hH7SpaD3ZbXi3sc0x0kSbyPScS2LOpSoCH4xbTR090VAK
1hbsZBMszTu3sI089EHzWaQ6FuPQONXONEKzSOG7WWk7Y1alfhjUMuRNTQHIxj0R
xjIzHK8N71RWK3qJkPloQKZwCC83saNAWknj+w0oO5JNvt6NHobPJzBogfmZqFov
VYqQFrvG/Vy0ff3tGrpvQkSyUvNtsvL50lY8CCj37OJ0H0XiVHbZxblvBU6hFGgN
bU6+wN7fmm++iS9Jk39qsIGzsFB1MWKqwcUdrkvUo04U5HfFtpoko6hqGldYKpxh
QUktAat9U2n/DtHAcscUzs8odrN9hRnvi2ENIURrsM3EWYYJZYU=
=kUBK
- -END PGP SIGNATURE-

php-8.1.0.tar.xz
SHA256 hash:
a1317eff0723a2b3d3122bbfe107a1158570ea2822dc35a5fb360086db0f6bbc
PGP signature:
- -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmGdOboACgkQGZ+d/vb/
uv29OQ/+MTwutRkruh5cqqrfCsAHUq8zaIsb5e2aQnaOhVZ93S/tfEKxQjVaGLyQ
6D0eZtToCr/yGE3LCl5514OpgF2yf6Nvpx1xtHlVcsYY94ULChBTDGyng7wlxRx3
aAZRBNqUHtVCN/ZluzCndcbc32j05ukIjFLYM3OuEY9pK7DbrW+EAt4LA67uffSL
0pdrFTVNVFvUsoykN40rixCR4vDyAGocHOq90MjYj/VBy/1I9wN87pV55qt3E9xw
XnYX6M3ZZHeaqmiDv7EcN7vf47qtbmQM5XEn5iUnFDY6HCyLkvjgkTNJhY9FrXxp
4ciRWzTbzHQ+8TF8SG3CVdFnTe1rTAtHvorq4A6VV7FB7zeAvkTJNLaIfs6/YULp
hMLk6A/N/gGpM7qgJwgB2Cg2DGOYyHK0dxJ1l5CaRIFOT2xBSUI5O3YdC40o7UyD
Zh3iN7X8aLCcfqCdGgBlVaIjLCMvhqtlJU3JKMlp3A3cgXlyRcr72eT3lBH3J/QE
UZECfudsHFzNdE6FZu0sVTm+oDd7CHPJboS06CuwcuElxHZHhS9e6kfmNvNTBw6g
8vHDS5tq8kqiox8R1sSGN9gCSH1EkI2Em+G0JFouTap2/UNl8/jCcvdKL+kdjydH
TQs21fi59WE7BXJjymbnUozLRx3owLmDxo3U9IInUKwRLUnYmZU=
=jy/h
- -END PGP SIGNATURE-

- --
- -Patrick
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.2.0
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCgAGBQJhn9QIACEJEBmfnf72/7r9FiEE8faSI4+8FmblpczUGZ+d
/vb/uv2Wbg//ez78B7V8fv9JD6L4tUPNuGuyfPLvRScvOZImAxSg8dOedoRU
Ml+6RxtyvMowZlCLHip6S43vELcktPGOybHgFAk5iUrATvZxPq/YI6BhN5yb
op3DKVJvZzvHX7dhO8eKhyGMYr7jK6g3l4LjEwvHvIaiFVNFERbNeQmwp129
ShlM4DZikZlRdhYX8gW+Wui2tdl3ZSO097daeGATATZS49FwJaqpICQra6D2
nc7HsPEmBB93iNM3+P2olAvj6AykBAKHslfifsmJSCm0WvRDCDSeK9Y0/qvV
d6gBNmk0f8iKpbOKhxRUWzo4EslgMMssOTlM+guwfhZwmwk8Opv+rheJtLKu
B7C3zjT4Fg9fy9jua2z4cwj51kc4eepmMDyMNTq7PZxrA7R/CfsAvDVE8B+l
tZ9qZCmNCNkakoPxrZ0mY9P80aW0L4iRgFdMiECEKR0J5OghTLyuvakDXWhP
uwq8/M/8lcuYAApUT9T5kOwSvhiYyEKT/dRlikuh6Mhh8rdEfuuNzOebSNN0
CCHOg5LJnwpRxzmxTcZabEHFw+cXcG4aOq/Vx8Ix1/bafw033a2fv9FUAWvm
Yp4Sw+uVTUpaL/Gf7652CHFTs1CVkaAMyWk1OOZV8FpDVdStRsPNXFoJ2QBw
MgNdFJZ9cstoJeH/QEr8//cO0dzjiyZw7Mc=
=naQL

Re: [PHP-DEV] Automatic performance benchmarking: PHP 8.1 is ~30% faster than PHP 7.4

[Máté Kocsis]

Sorry Folks, but I have to provide some update about the results:

Unfortunately, due to a silly bug in my calculator code, the % differences
in the benchmark results were slightly off from their real values, so I
have just retroactively adjusted them.
In fact, the Symfony demo app on PHP 8.1 is ~23% faster than on PHP 7.4,
while Laravel runs ~21.5% faster on PHP 8.1 than on PHP 7.4. In my opinion,
this performance increase
is still very remarkable, so I'm not disappointed at all that the
improvement is slightly less dramatic than I previously suggested. In any
case, sorry for the misleading news!

I wish a happy PHP 8.1 release party to everyone:
Máté

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

[Nikita Popov]

On Fri, Nov 12, 2021 at 2:07 PM Nikita Popov  wrote:

> Hi internals,
>
> I've opened the vote on
> https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> 2021-11-26.
>
> Regards,
> Nikita
>

As a reminder, voting on this RFC closes tomorrow. I usually don't specify
an exact time, but as the margin is so narrow: I plan to close the vote at
9am UTC.

Regards,
Nikita

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

[Dan Ackroyd]

On Thu, 25 Nov 2021 at 05:05, Tim Starling  wrote:
>
> Voting is now open for my RFC on locale-independent case conversion.
>

It seems popular, and likely to pass, but I voted no as the "Backward
Incompatible Changes" section is missing which makes it hard to
evaluate the impact.

cheers
Dan
Ack

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

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

[Paul Crovella]

On Thu, Nov 25, 2021 at 3:14 AM Tim Starling  wrote:
>
> On 25/11/21 7:57 pm, Côme Chilliet wrote:
>
> > To reuse the example from the RFC, if I want to convert a UTF string to 
> > uppercase using Turkish rules and get dotted capital I, what should I use?
>
> For case-insensitive comparison you can use Collator. But for display
> you just have to do it yourself. For the Turkish Wikipedia and other
> Turkic language websites we are currently using str_replace().

Any particular reason not to use transliterators? https://3v4l.org/I038T

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

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

[Nicolas Grekas]

Le jeu. 25 nov. 2021 à 12:23, Tim Starling  a
écrit :

> On 25/11/21 8:58 pm, Nicolas Grekas wrote:
>
>
> The RFC says:
> > because they also use isdigit() and isspace(),
>
> Does that mean "too much work needed"? I would totally understand that of
> course but I hope someone could do these last miles.
>
> Yes.
>
> > and because they are intended for natural language processing
>
> I definitely do not agree with this argument and it should be removed from
> the RFC to me as it might add confusion in the future.
>
> Done.
>

Great, thanks!

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

[Tim Starling]

On 25/11/21 8:58 pm, Nicolas Grekas wrote:
>
> The RFC says:
> > because they also use isdigit() and isspace(),
>
> Does that mean "too much work needed"? I would totally understand
> that of course but I hope someone could do these last miles.
>
Yes.

> > and because they are intended for natural language processing
>
> I definitely do not agree with this argument and it should be
> removed from the RFC to me as it might add confusion in the future.

Done.

-- Tim Starling

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

[Tim Starling]

On 25/11/21 7:57 pm, Côme Chilliet wrote:
> Hello,
>
> The RFC is missing information about alternatives:
> Do all of these function have an mbstring version?

The following functions have an mbstring version: strtolower,
strtoupper, stristr, stripos, strripos.

mb_convert_case() provides functionality equivalent to lcfirst,
ucfirst and ucwords.

There is no mbstring version of str_ireplace, that is
https://bugs.php.net/bug.php?id=75225

There is no mbstring equivalent for the array sorting functions with
SORT_FLAG_CASE, but there is Collator::asort() in intl.

> Are those locale dependant or have an option for it?

The mbstring functions are locale-independent.

Unfortunately there do not seem to be PHP wrappers for the family of
case conversion functions in ICU's ustring.h. There is
IntlChar::tolower() and IntlChar::toupper(), but they provide
locale-independent case conversion, equvialent to mbstring. It's not
ideal to change the case of a string character by character, since
some languages have multi-character mappings. ICU calls this
context-sensitive case conversion.

Considering the lack of wide character support or context-sensitive
case conversion in the existing strtoupper/strtolower, I would
consider this missing functionality rather than functionality which I
am removing.

> To reuse the example from the RFC, if I want to convert a UTF string to 
> uppercase using Turkish rules and get dotted capital I, what should I use?

For case-insensitive comparison you can use Collator. But for display
you just have to do it yourself. For the Turkish Wikipedia and other
Turkic language websites we are currently using str_replace().

-- Tim Starling

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

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

[Nicolas Grekas]

Le jeu. 25 nov. 2021 à 11:34, Christoph M. Becker  a
écrit :

> On 25.11.2021 at 10:58, Nicolas Grekas wrote:
>
> > Le jeu. 25 nov. 2021 à 10:47, Tim Starling  a
> > écrit :
> >
> >> and because they are intended for natural language processing
> >
> > I definitely do not agree with this argument and it should be removed
> from
> > the RFC to me as it might add confusion in the future.
>
> Yeah, the PHP manual says[1]:
>
> | This function implements a comparison algorithm that orders
> | alphanumeric strings in the way a human being would, this is described
> | as a "natural ordering".
>
> [1] 
>

Yep, yet "natural language processing" means processing sentences we write
as humans, e.g. processing this very message. natcase sorting functions are
not done for that. They're useful to sort items in a list - typically file
names - in a way that makes sense to humans. This is very different from
"natural language processing". Having "natsort" vary by locale doesn't make
more sense than having "sort()" vary by locale. That's my point. The
argument doesn't stand against implementing locale-insensitivity for these
functions and I think the RFC shouldn't make it (the argument.)

Nicolas

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

[Christoph M. Becker]

On 25.11.2021 at 10:58, Nicolas Grekas wrote:

> Le jeu. 25 nov. 2021 à 10:47, Tim Starling  a
> écrit :
>
>> and because they are intended for natural language processing
>
> I definitely do not agree with this argument and it should be removed from
> the RFC to me as it might add confusion in the future.

Yeah, the PHP manual says[1]:

| This function implements a comparison algorithm that orders
| alphanumeric strings in the way a human being would, this is described
| as a "natural ordering".

[1] 

--
Christoph M. Becker

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

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

[Nicolas Grekas]

Le jeu. 25 nov. 2021 à 10:47, Tim Starling  a
écrit :

> On 25/11/21 7:55 pm, Nicolas Grekas wrote:
>
>
> I voted yes because I want to see this happen but I raised a point in
> https://externals.io/message/116141#116259 and didn't get an answer:
>
> Despite their name, I never used natcase functions for natural language
>> processing. I use them eg to sort lists of files in a directory, to
>> account
>> for numbers mainly. But that's not what I would call natural language
>> processing. I'm not aware of anyone using them for that actually. I'm
>> wondering if it's a good idea to postpone migrating them to an
>> hypothetical
>> future as to me, the whole reasoning of the RFC applies to them.
>>
>
> I wish the strnatcasecmp() and natcasesort() function, but also the
> SORT_NATURAL flag were also covered by this RFC.
> Is that possible? Would it make sense?
>
>
> I'm not going to migrate those functions at this time. It's just a project
> scope decision.
>

Why?

The RFC says:
> because they also use isdigit() and isspace(),

Does that mean "too much work needed"? I would totally understand that of
course but I hope someone could do these last miles.

> and because they are intended for natural language processing

I definitely do not agree with this argument and it should be removed from
the RFC to me as it might add confusion in the future.

Nicolas

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

[Tim Starling]

On 25/11/21 7:55 pm, Nicolas Grekas wrote:
>
> I voted yes because I want to see this happen but I raised a point
> in https://externals.io/message/116141#116259
>  and didn't get an answer:
>
> Despite their name, I never used natcase functions for natural
> language
> processing. I use them eg to sort lists of files in a directory,
> to account
> for numbers mainly. But that's not what I would call natural
> language
> processing. I'm not aware of anyone using them for that
> actually. I'm
> wondering if it's a good idea to postpone migrating them to an
> hypothetical
> future as to me, the whole reasoning of the RFC applies to them.
>
>
> I wish the strnatcasecmp() and natcasesort() function, but also the
> SORT_NATURAL flag were also covered by this RFC.
> Is that possible? Would it make sense?


I'm not going to migrate those functions at this time. It's just a
project scope decision.

-- Tim Starling

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

[Dusk]

On Nov 25, 2021, at 01:08, Hans Henrik Bergan  wrote:
> btw why is this code *not* getting dotted capital i on 3v4l?
> https://3v4l.org/D1WG1#v7.4.26
> it gets ["res_hex"]=> string(2) "49"
> 
>  setlocale(LC_ALL, "Turkish");

Because "Turkish" isn't a locale. "tr_TR" is.

https://3v4l.org/GD91W#v7.4.26

Notice that the output doesn't show up correctly, as it is not UTF-8. (Which is 
part of the problem addressed by this RFC.)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Hans Henrik Bergan]

btw why is this code *not* getting dotted capital i on 3v4l?
https://3v4l.org/D1WG1#v7.4.26
it gets ["res_hex"]=> string(2) "49"

$str,
"str_hex"=>bin2hex($str),
"res"=>$res,
"res_hex"=>bin2hex($res),
]);
?>

On Thu, 25 Nov 2021 at 09:57, Côme Chilliet  wrote:

> Le jeudi 25 novembre 2021, 06:05:37 CET Tim Starling a écrit :
> > Voting is now open for my RFC on locale-independent case conversion.
> >
> > https://wiki.php.net/rfc/strtolower-ascii
>
> Hello,
>
> The RFC is missing information about alternatives:
> Do all of these function have an mbstring version?
> Are those locale dependant or have an option for it?
>
> To reuse the example from the RFC, if I want to convert a UTF string to
> uppercase using Turkish rules and get dotted capital I, what should I use?
>
> Côme
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

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

[Côme Chilliet]

Le jeudi 25 novembre 2021, 06:05:37 CET Tim Starling a écrit :
> Voting is now open for my RFC on locale-independent case conversion.
> 
> https://wiki.php.net/rfc/strtolower-ascii

Hello,

The RFC is missing information about alternatives:
Do all of these function have an mbstring version?
Are those locale dependant or have an option for it?

To reuse the example from the RFC, if I want to convert a UTF string to 
uppercase using Turkish rules and get dotted capital I, what should I use?

Côme

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

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

[Nicolas Grekas]

Le jeu. 25 nov. 2021 à 06:05, Tim Starling  a
écrit :

> Voting is now open for my RFC on locale-independent case conversion.
>
> https://wiki.php.net/rfc/strtolower-ascii
>
> Voting will close in two weeks, on 2021-12-09.
>

Hi Tim,

I voted yes because I want to see this happen but I raised a point in
https://externals.io/message/116141#116259 and didn't get an answer:

Despite their name, I never used natcase functions for natural language
> processing. I use them eg to sort lists of files in a directory, to account
> for numbers mainly. But that's not what I would call natural language
> processing. I'm not aware of anyone using them for that actually. I'm
> wondering if it's a good idea to postpone migrating them to an hypothetical
> future as to me, the whole reasoning of the RFC applies to them.
>

I wish the strnatcasecmp() and natcasesort() function, but also the
SORT_NATURAL flag were also covered by this RFC.
Is that possible? Would it make sense?

Nicolas

Re: [PHP-DEV] Need Update regarding PHP Travis CI Execution

[Nikita Popov]

On Wed, Nov 24, 2021 at 12:42 PM Chandranana Naik 
wrote:

>
> Hi Team,
>
> Recently Travis builds have stopped running for PHP.
> We only see Cirrus and appveyor CI builds,  however travis.yml exists in
> the github repo.
>
> Could you please update if Travis builds will be started again or if there
> are plans to disable Travis CI support ?
>
> Regards,
> Chandranana
>

Travis is working again.

Regards,
Nikita