Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123603
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-515-g87b2bad5a-fm-20240604.001-g87b2bad5
Precedence: bulk
MIME-Version: 1.0
Message-ID: <923a3373-1963-4239-b218-bcdada899024@app.fastmail.com>
In-Reply-To: 
 <CAPzBOBM-bULK-3S1aFzDgf5qcpw_jn9_N2KHAJB1sWm3gCVSWA@mail.gmail.com>
References: 
 <CAPyeZ4O2rK+2ApuE-YLc7j_Z2LcT29yHcLYXvB0oGs-D_zTSag@mail.gmail.com>
 <CAMjSS5OPKm0dRP+ckCdpBd4Kg1aRhU5QgcuTWwPTnyC_1aZRkw@mail.gmail.com>
 <CAPyeZ4PCGuosZMrj9jvwXQnBuSdoqXsVFEEArUDpOkxTMk_h+Q@mail.gmail.com>
 <CAF-mU4yqj_sWPFJPmAsP6gHKguWVa5NfXto2qAvfdMm0G342CQ@mail.gmail.com>
 <CAPzBOBM-bULK-3S1aFzDgf5qcpw_jn9_N2KHAJB1sWm3gCVSWA@mail.gmail.com>
Date: Fri, 14 Jun 2024 14:56:14 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] Revisiting case-sensitivity in PHP
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jun 14, 2024, at 11:22 AM, Robert Landers wrote:
> On Fri, Jun 14, 2024 at 6:40=E2=80=AFAM Rokas =C5=A0leinius <raveren@g=
mail.com> wrote:
>>
>> I'm no one important, but I just want to say for the sake of the
>> public image of PHP I hope this does not pass, or at least not in the
>> foreseeable future.
>>
>> There are NO substantial gains to speak of here and the BC break is
>> real and it's super annoying when they pile up and up.
>>
>> Besides, this is slightly off topic, but I don't know if you know, but
>> if you take a look at stackoverflow developer survey over the years,
>> there has been an absolute 30% drop of php popularity in the past few
>> years.
>>
>> I would guess this is mostly the low-level developers not being fans
>> of the language removing magic quotes and other "super useful"
>> features. In other words, PHP lost the average joe as its target
>> audience. Joe's gone.
>>
>> Just my 2=C2=A2:
>> a) this WAS the reason PHP was great and I loved to rewrite the
>> systems of several very successful companies who started out with
>> their non-technical founders who coded their way out of the box to
>> begin multi-million businesses
>> b) the PHP core and co. (a.k.a. YOU) should be acutely aware that the
>> language needs to be liked by not only you, dear awesome lovely
>> hardcore nerds, but also the users who just need to get stuff done,
>> business needs fulfilled.
>>
>> I know this is not how YOU work, but if you ignore that part of the
>> language users, there might eventually not be a language to work on in
>> the future.
>>
>> So please, keep the language loose, I hate the slight inconsistency
>> too, but if we ruin the day for another 20% of users, it might even be
>> the straw that broke the camel's back.
>>
>> On Fri, 14 Jun 2024 at 02:38, Valentin Udaltsov
>> <udaltsov.valentin@gmail.com> wrote:
>> >
>> > On Friday, 14 June, 2024=E2=80=AF=D0=B3. at 00:04, Timo Tijhof <tti=
jhof@wikimedia.org> wrote:
>> >>
>> >> Would this affect unserialize()?
>> >>
>> >> I ask because MediaWiki's main "text" database table is an immutab=
le/append-only store where we store the text of each page revision since=
 ~2004. It is stored as serialised blobs of a value class. There have be=
en a number of different implementations over the past twenty years of W=
ikipedia's existence (plain text, gzip-compressed, diff-compressed, etc.=
).
>> >>
>> >> When we adopted modern autoloading in MediaWiki, we quickly found =
that blobs originally serialized by PHP 4 actually encoded the class in =
lowercase, regardless of the casing in source code.
>> >>
>> >> From https://3v4l.org/jl0et:
>> >>>
>> >>> class ConcatenatedGzipHistoryBlob {=E2=80=A6}
>> >>> print serialize($blob);
>> >>> # PHP 4.x: O:27:"concatenatedgziphistoryblob":=E2=80=A6
>> >>> # PHP 5/7/8: O:27:"ConcatenatedGzipHistoryBlob":=E2=80=A6
>> >>
>> >>
>> >> It is of course the application's responsibility to load these cla=
sses, but, it is arguably PHP's responsiblity to be able to construct wh=
at it serialized. I suppose anything is possible when announced as a bre=
aking change for PHP 9.0. I wanted to share this as something to take in=
to consideration as part of the impact. Potentially worthy of additional=
 communicating, or perhaps worth supporting separately.
>> >>
>> >> --
>> >> Timo Tijhof,
>> >> Principal Engineer,
>> >> Wikimedia Foundation.
>> >> https://timotijhof.net/
>> >>
>> >
>> > Hi, Timo!
>> >
>> > Thank you very much for bringing up this important case.
>> >
>> > Here's how I see this. If PHP gets class case-sensitivity, unserial=
ization of classes with lowercase names will fail. This is because the e=
ngine will start putting `MyClass` class entry with key `MyClass` (not `=
myclass`) into the loaded classes table and serialization will not be ab=
le to find it as `myclass`.
>> > Even if some deprecation layer is introduced (that puts both `mycla=
ss` and `MyClass` keys into the table), you will first have a ton of not=
ices and then eventually end up with the same problem, when transition t=
o case sensitivity is complete. Hence I propose no deprecation layer =E2=
=80=94 it does not really help.
>> >
>> > However, you will be able to use `class_alias()` to solve your issu=
e. If classes are case-sensitive, `class_alias(MyClass::class, 'myclass'=
);` should work, since MyClass !=3D myclass anymore. And serialization w=
orks perfectly with class aliases, see https://3v4l.org/1n1as .
>> >
>> > --
>> > Valentin Udaltsov
>> >
>
> Hey Rokas,
>
> Please bottom post (it's the rules), but PHP's "decline" has little to
> do with the language itself, most likely it has to do with how long
> people have been coding. >42% of people have been programming less
> than 9 years, and >62% for less than 14. "Hyped up" languages tend to
> dominate in the earlier years of programming and even then, most of
> the developers responding to that survey classify themselves as
> "full-stack" (and from talking to "full-stack" developers, it mostly
> tends to mean they know Javascript -- which lo-and-behold, is the top
> language; surprise surprise).
>
> I wouldn't put too much weight on that survey since it is clearly
> biased towards early-career devs, in the US, who know Javascript.
> Fortunately, the industry is much bigger than that.
>
> Robert Landers
> Software Engineer
> Utrecht NL

While the whining about market share is off topic, the challenges of kee=
ping up with upgrades are valid, and have been expressed many times.  (S=
ometimes more politely than others.)

I agree that this sounds like a change with very unclear BC implications=
 at best, and bad ones at worst, with dubious benefit.  Just how much pe=
rformance would we gain from case sensitive class names?  If it's 20%, O=
K, sure, that may be worth whatever BC breaks that causes on the margins=
.  If it's 0.2%, then frankly, no, the PR cost of pissing off people who=
 have to manage edge cases is not worth the hassle.

At the moment, I'm leaning No on this change, because the cost/reward/ba=
cklash ratio is just not there to support it.

--Larry Garfield