Coming from the property hooks/ asymmetric visibility dude, that's pretty rich.
On Fri, Jun 14, 2024 at 10:13 AM Larry Garfield <la...@garfieldtech.com> wrote: > On Fri, Jun 14, 2024, at 11:22 AM, Robert Landers wrote: > > On Fri, Jun 14, 2024 at 6:40 AM Rokas Šleinius <rave...@gmail.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¢: > >> 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.valen...@gmail.com> wrote: > >> > > >> > On Friday, 14 June, 2024 г. at 00:04, Timo Tijhof < > ttij...@wikimedia.org> wrote: > >> >> > >> >> Would this affect unserialize()? > >> >> > >> >> I ask because MediaWiki's main "text" database table is an > immutable/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 > been a number of different implementations over the past twenty years of > Wikipedia'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 {…} > >> >>> print serialize($blob); > >> >>> # PHP 4.x: O:27:"concatenatedgziphistoryblob":… > >> >>> # PHP 5/7/8: O:27:"ConcatenatedGzipHistoryBlob":… > >> >> > >> >> > >> >> It is of course the application's responsibility to load these > classes, but, it is arguably PHP's responsiblity to be able to construct > what it serialized. I suppose anything is possible when announced as a > breaking change for PHP 9.0. I wanted to share this as something to take > into 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, > unserialization of classes with lowercase names will fail. This is because > the engine will start putting `MyClass` class entry with key `MyClass` (not > `myclass`) into the loaded classes table and serialization will not be able > to find it as `myclass`. > >> > Even if some deprecation layer is introduced (that puts both > `myclass` and `MyClass` keys into the table), you will first have a ton of > notices and then eventually end up with the same problem, when transition > to case sensitivity is complete. Hence I propose no deprecation layer — it > does not really help. > >> > > >> > However, you will be able to use `class_alias()` to solve your issue. > If classes are case-sensitive, `class_alias(MyClass::class, 'myclass');` > should work, since MyClass != myclass anymore. And serialization works > 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 > keeping up with upgrades are valid, and have been expressed many times. > (Sometimes 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 > performance would we gain from case sensitive class names? If it's 20%, > OK, 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/backlash ratio is just not there to support it. > > --Larry Garfield >
