Coming from the property hooks/ asymmetric visibility dude, that's pretty
rich.
On Fri, Jun 14, 2024 at 10:13 AM Larry Garfield <[email protected]>
wrote:
> On Fri, Jun 14, 2024, at 11:22 AM, Robert Landers wrote:
> > On Fri, Jun 14, 2024 at 6:40 AM Rokas Šleinius <[email protected]>
> 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
> >> <[email protected]> wrote:
> >> >
> >> > On Friday, 14 June, 2024 г. at 00:04, Timo Tijhof <
> [email protected]> 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
>