Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124153 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 9745D1A009D for ; Mon, 1 Jul 2024 17:28:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719855008; bh=HjVaqWNi5NG6xbDRxVDx5AqHGaL7whFFL0GCkTBJHSc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ZxxsQs3lRy3pfCHeMzGZi2FocTziwW/lD0tIV1UeMzMf0lCqfGKNJ9qH4z3BcEfqP RnbCxdG4T8KdSjRQrMth3I0CvdbOz7PLeQpqyY9KlkKTJg/j4WT4BawJwFqfWAvfZv IKYmkPtqA3aIIdwW9ZnBuYWBohuyrC0JQnIog1Iz4XU+/JEuviUidVlN9xUCgAI7sA 8Qup3I67PemhGBPYERbzwi87n4G9izM1U7mjJPLWxhjcX2PmI/I7i4r0sskBYJGGjP wVLa+vwwkVnJPPRNDmvKXHOPUWzdhVd+J9f60atuIPTHxJLStLZZZfpmS+2Mr73G+K 5su/je4/DCSKg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 41C4D180642 for ; Mon, 1 Jul 2024 17:30:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 1 Jul 2024 17:30:01 +0000 (UTC) Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-361785bfa71so2364183f8f.2 for ; Mon, 01 Jul 2024 10:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719854919; x=1720459719; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fQbbIz11H2IuUYlpIpik31f6hWGECoUF/ZUNbQIn/xQ=; b=RsAIZydOgsGeb23aK0JV4RYeXABXy7jDkF3SzszEbSDZM3y203QUwIc5/h1lKajvMM 8j++DtMGQUN3W41pMxeCRk66Ab23pvVMaOoAEEoDP6mhHyFwxjlU5dfocummtjL8ObZR afls93jQAt04fOWsYxchyRLlQ1DrnvPCGFARg2wRcewlQ22/qZnFCxkBPY6TVxVqruME Y3iSwg1L7JnbOzybje894S97dkdOgWz0DMFG895jYmU5A951+8Upg5d/cCI8ur3Zrlnk ueBzADoK2IIy19/EhnOAIrd6NUd0eEXFYv64FlX8/vAy+4Ip8KRtacomCIhnOiUhRA/f 2tbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719854919; x=1720459719; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fQbbIz11H2IuUYlpIpik31f6hWGECoUF/ZUNbQIn/xQ=; b=DORFNlnPPq8/YarTZOCnDVaeVz9P1Jzqn+7PMuLImltp+DJoY4up3Vp6SaYeBGF1Sl GUApZEDNm7w5tMeqt8HeHkA6Pvzltxrr2q2h+ccDL7IBp3sP/b1QALx7UFdgbgICsxMc NstgCn9UMrpMaRXbSzI4ShH1zbdAdnwRoUd05vScOB2Mn0yR4TgKPGX+lBo3Zy/P5YOJ rxZUFMB7uuBy0+5sZrp4xT/yv4sZTuscO8arZOBklkpzkO2wV3OEYW9A56Uai5jCCXwt SluP+Xc96tLI3VpGQuOncAcPryt8czcosTA4L550FrGTMJWYXB2ahk1wZh1i/itxrCZx L31g== X-Gm-Message-State: AOJu0YyFh975v9jYRkYFuMiMabC34YIUXX/kw00Di09S6hmhdCjZy0Ms gMEz+42juZJRqL8wNoLn1sx4GMaX3uAe05aqFyPf02XsVAaqrUO1HcmV8IRJMZ8NISXS4HjJlDi 1oipqTsqcrazUis37ZVTX/nmHnKOU/Q== X-Google-Smtp-Source: AGHT+IHj7gTLKkGZw4uX9WiEeAeyaiOme3LwGSQF6UZbbMB+Vzf3sNvGA3R2o3NDRra+4Uk9/w1rJvP60zdW3PLMLBs= X-Received: by 2002:a05:6000:402a:b0:366:e8e4:599f with SMTP id ffacd0b85a97d-36775699b80mr6037314f8f.7.1719854919341; Mon, 01 Jul 2024 10:28:39 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: <1917CF7C-26D8-4DBE-B05C-5AA650AC6C9F@rwec.co.uk> <551cd5b0-1c00-4818-a9ca-97f6b7e8c3dc@app.fastmail.com> <39B496F8-062E-4848-9B3B-529BE8D3415A@newclarity.net> <856F4F70-DC81-4098-82DD-5F6D47CDF3F0@newclarity.net> <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net> In-Reply-To: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net> Date: Mon, 1 Jul 2024 20:28:02 +0300 Message-ID: Subject: Re: [PHP-DEV] Iteration III: Packages (was Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript) To: Mike Schinkel Cc: PHP internals Content-Type: multipart/alternative; boundary="000000000000885e0a061c32edf7" From: arvids.godjuks@gmail.com (Arvids Godjuks) --000000000000885e0a061c32edf7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 1 Jul 2024 at 19:22, Mike Schinkel wrote: > > On Jul 1, 2024, at 7:57 AM, Arvids Godjuks > wrote: > > > > TL;DR: As a userland developer, in my opinion, this is just a downgrade > from what we have now. Enhance namespaces to have the ability to have > internal/private classes, interfaces, enums and constants. That's about i= t. > > Please note my comments that follow do not mean I am in support of this > package proposal as presented. > > > Autoloading is one of the best killer features of PHP - love it or hate > it - it's your personal preference. > > Two really solid reasons to hate autoloading as implemented in PHP: > > 1. Autoloading runs userland code. This means it has the potential > conflict between different packages with different autoloaders, it means > there can be buggy autoloaders, and it means that when using XDEBUG every > time a new symbol is found when the developer is single-step debugging th= e > developer will be dropped into the autoloader and then best case they the= n > immediately trace out. All of these aspects a major PITA and time waster > and make debugging more exhausting than it needs to be. > But that is why interoperability in PHP world is so high. When it was introduced, it allowed enabling autoloading for most code bases out there regardless of what their structure was and still is. Sure, you have to be careful how you do it, but that is also not really a userland concern - most of those have been implemented once and then almost never touched :) The community has settled on a general approach since naturally and that's how vast majority of people write their code. Buggy code is buggy code, it really has not much to do with the autoloading and with how people write buggy code :) You are blaming the hammer for user trying to nail the screw into wood :) You can already sidestep autoloader by adding a require statement to any file and loading everything without triggering autoload. You can add your own autoloader that has a map of high-level namespaces where you want to load it as a package and recursively include everything that way. The tools are there, you just need to use them. If anything, since PHP now has attributes, you can just make yourself an attribute and handler for it and have a `#[Package('name')]` that can find all files with that attribute and load it all as a package. It's far more powerful in userland because it allows people to do whatever they want with it if they do not like the standard autoloader(s). If anything, combined with composer folks, PHP-FIG could come up with a community based `#[Package]` tag and make packages a thing. > > 2. Autoloading effectively necessitates that every symbol be in its own > separate file. This needlessly bloats number of files and directories by > more than an order of magnitude =E2=80=94 see my numbers from recent disc= ussion =E2=80=94 > and that also mean related code is located farther away from other relate= d > code. This can be worked around but the workarounds I've seen are all > fragile and unable to be generic, and few 3rd party packages do this. > That's just how PSR-4 standard was written and works, and it's a good default for a reason. On small projects - sure, I can see it being overkill. But I haven't worked on a small project in a decade and I rarely have that little code in one file that I would want to stuff all together in one file. I do use PHPStorm, so it is very adapted to how most PHP projects are and provides excellent navigation abilities that fit the PSR-4 and that way of structuring projects. Vast part of the community uses it. It's a standard in a lot of companies for a reason. > > > I've seen a sizeable chunk of developers that come from other languages > discover PHP's autoloading and their minds just get blown. > > It is unclear to me if by saying their "minds just get blown" if that > means you think they see it as a positive or negative? > In a positive manner - a lot of people love that they do not have to fiddle with import statements and just can leave that part to the ecosystem and IDE to figure out. > > As a developer who spent a decade in PHP and then branched out and added > Go to my repertoire I can tell you one of the nicest differences I > experienced was not having to deal with an autoloader during debugging, a= nd > not being so constrained was to have to create a new file for every symbo= l. > Go projects need an order of magnitude fewer files. It is just so much > easier to grok the source code of a Go project compared to a PHP because = of > this one simple fact. Now when I program in PHP I find myself constantly > cursing the fact that I have to deal with the autoloader. > > BTW, I know Go is a pre-compiled language unlike PHP, but that does not > necessarily preclude PHP from having a better solution for code loading a= nd > organization. > See my reply to autoloading things above - you can eliminate the autoloader triggering easily in probably 15-30 minutes flat. > > > Performance has not been an issue for a long time due to opcache and al= l > the optimizations that have been done to it and ability to preload > bytecode. Then there are things like FrankenPHP, Swoole, ReactPHP and > others that entirely sidestep that issue. And then there's the active > development of JIT engine - just let the people working on the > implementation time to cook. > > This reads to me like Stockholm syndrome, e.g. "My captors still hold me > captive, but they no longer beat me every day." > It's not that, it's literally true. PHP is one of the fastest-interpreted languages, butting heads with nodejs only losing to it in default simple application implementations because PHP is not event loop first (but Franken PHP and others have a few things to say about that and then there have been recently people playing with fibers and stuff and got performance results that showed PHP being faster than nodejs at higher loads. Sorry I do not have a link handly :\ ) > > > It works, worked for a long time and there are not so many things wrong > with it to entirely upend the whole ecosystem and split the language. > Here's your HARD REMINDER about Python 2 =3D> Python 3 and how that went = and > is still somewhat ongoing. > > Totally agree on that. > > -Mike There are aspects to this that go beyond just technical aspects. Wherever when implementing autoloading people were secret geniuses, stumbled into it accidentally or just had practical needs themselves that they just implemented in this way - it has been a major turning point in PHP's life and has transformed the ecosystem into what it is today together with the rise of the composer package manager. I have seen people talk about visibility in namespaces, package concept and all that, but every time it was building upon existing autoloading mechanics - some adding capabilities to them, modifying them, having new type of autoloader. But I have never encountered anyone in this community in 20 years i have been an active part of it to propose a radical change like this and I'm fairly certain after keeping up with the thread that it is almost universally not what people want. Most people just want the toolbox be "finished" so to speak, not get a completely new one in addition that has no compatibility with the old one= . To be frank, the PHP ecosystem just does not have the resources to eat a change on that level and support more than one implementation. Unlike many other languages, PHP does not really get support and investment from the likes of google, Microsoft, meta and so on. PHP Foundation is great, but it's not google that can singlehandedly throw 1000 devs at supporting a language and not even really feel it. --=20 Arv=C4=ABds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Telegram: @psihius https://t.me/psihius --000000000000885e0a061c32edf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, 1 Jul 2024 at 19:22, Mike Sch= inkel <mike@newclarity.net>= ; wrote:
> On= Jul 1, 2024, at 7:57 AM, Arvids Godjuks <arvids.godjuks@gmail.com> wrote:
>
> TL;DR: As a userland developer, in my opinion, this is just a downgrad= e from what we have now. Enhance namespaces to have the ability to have int= ernal/private classes, interfaces, enums and constants. That's about it= .

Please note my comments that follow do not mean I am in support of this pac= kage proposal as presented.

> Autoloading is one of the best killer features of PHP - love it or hat= e it - it's your personal preference.

Two really solid reasons to hate autoloading as implemented in PHP:

1. Autoloading runs userland code. This means it has the potential conflict= between different packages with different autoloaders, it means there can = be buggy autoloaders, and it means that when using XDEBUG every time a new = symbol is found when the developer is single-step debugging the developer w= ill be dropped into the autoloader and then best case they then immediately= trace out. All of these aspects a major PITA and time waster and make debu= gging more exhausting than it needs to be.

<= div>But that is why interoperability in PHP world is so high. When it was i= ntroduced, it allowed enabling autoloading for most code bases out there re= gardless of what their structure was and still is. Sure, you have to be car= eful how you do it, but that is also not really a userland concern - most o= f those have been implemented once and then almost never touched :) The com= munity has settled on a general approach since naturally and that's how= vast majority of people write their code. Buggy code is buggy code, it rea= lly has not much to do with the autoloading and with how people write buggy= code :) You are blaming the hammer for user trying to nail the screw into = wood :)=C2=A0

You can already sidestep autoloader = by adding a require statement to any file and loading everything without tr= iggering autoload. You can add your own autoloader that has a map of high-l= evel namespaces where you want to load it as a package and recursively incl= ude everything that way. The tools are there, you just need to use them. If= anything, since PHP now has attributes, you can just make yourself an attr= ibute and handler for it and have a `#[Package('name')]` that can f= ind all files with that attribute and load it all as a package.=C2=A0
=
It's far more powerful in userland because it allows people to do = whatever they want with it if they do not like the standard autoloader(s). = If anything, combined with composer folks, PHP-FIG could come up with a com= munity based `#[Package]` tag and make packages a thing.
=C2=A0

2. Autoloading effectively necessitates that every symbol be in its own sep= arate file. This needlessly bloats number of files and directories by more = than an order of magnitude =E2=80=94 see my numbers from recent discussion = =E2=80=94 and that also mean related code is located farther away from othe= r related code. This can be worked around but the workarounds I've seen= are all fragile and unable to be generic, and few 3rd party packages do th= is.
That's just how PSR-4 standard was written and= works, and it's a good default for a reason. On small projects - sure,= I can see it being overkill. But I haven't worked on a small project i= n a decade and I rarely have that little code in one file that I would want= to stuff all together in one file. I do use PHPStorm, so it is very adapte= d to how most PHP projects are and provides excellent navigation abilities = that fit the PSR-4 and that way of structuring projects. Vast part of the c= ommunity uses it. It's a standard in a lot of companies for a reason.
=C2=A0

> I've seen a sizeable chunk of developers that come from other lang= uages discover PHP's autoloading and their minds just get blown.

It is unclear to me if by saying their "minds just get blown" if = that means you think they see it as a positive or negative?
In a positive manner - a lot of people love that they do not have to = fiddle with import statements and just can leave that part to the ecosystem= and IDE to figure out.

As a developer who spent a decade in PHP and then branched out and added Go= to my repertoire I can tell you one of the nicest differences I experience= d was not having to deal with an autoloader during debugging, and not being= so constrained was to have to create a new file for every symbol. Go proje= cts need an order of magnitude fewer files. It is just so much easier to gr= ok the source code of a Go project compared to a PHP because of this one si= mple fact. Now when I program in PHP I find myself constantly cursing the f= act that I have to deal with the autoloader.

BTW, I know Go is a pre-compiled language unlike PHP, but that does not nec= essarily preclude PHP from having a better solution for code loading and or= ganization.
See my reply to autoloading things above -= you can eliminate the autoloader triggering easily in probably 15-30 minut= es flat.=C2=A0

> Performance has not been an issue for a long time due to opcache and a= ll the optimizations that have been done to it and ability to preload bytec= ode. Then there are things like=C2=A0 FrankenPHP, Swoole, ReactPHP and othe= rs that entirely sidestep that issue. And then there's the active devel= opment of JIT engine - just let the people working on the implementation ti= me to cook.

This reads to me like Stockholm syndrome, e.g. "My captors still hold = me captive, but they no longer beat me every day."
It's not that, it's literally true. PHP is one of the fastest-int= erpreted languages, butting heads with nodejs only losing to it in default = simple application implementations because PHP is not event loop first (but= Franken PHP and others have a few things to say about that and then there = have been recently people playing with fibers and stuff and got performance= results that showed PHP being faster than nodejs at higher loads. Sorry I = do not have a link handly :\ )

> It works, worked for a long time and there are not so many things wron= g with it to entirely upend the whole ecosystem and split the language. Her= e's your HARD REMINDER about Python 2 =3D> Python 3 and how that wen= t and is still somewhat ongoing.

Totally agree on that.

-Mike

There are aspects to this th= at go beyond just technical aspects. Wherever when implementing autoloading= people were secret geniuses, stumbled into it accidentally or just had pra= ctical needs themselves that they just implemented in this way - it has bee= n a major turning point in PHP's life and has transformed the ecosystem= into what it is today together with the rise of the composer package manag= er. I have seen people talk about visibility in namespaces, package concept= and all that, but every time it was building upon existing autoloading mec= hanics - some adding capabilities to them, modifying them, having new type = of autoloader. But I have never encountered anyone in this community in 20 = years i have been an active part of it to propose a radical change like thi= s and I'm fairly certain after keeping up with the thread that it is al= most universally not what people want. Most people just want the toolbox be= "finished" so to speak, not get a completely new one in addition= that has no compatibility with the old one.
To be frank, the PHP= ecosystem just does not have the resources to eat a change on that level a= nd support more than one implementation. Unlike many other languages, PHP d= oes not really get support and investment from the likes of google, Microso= ft, meta and so on. PHP Foundation is great, but it's not google that c= an singlehandedly throw 1000 devs at supporting a language and not even rea= lly feel it.
--

Arv= =C4=ABds Godjuks
+371 26 851 664
Te= legram: @psihius=C2=A0ht= tps://t.me/psihius
--000000000000885e0a061c32edf7--