On Fri, Jun 28, 2024, at 09:07, Michael Morris wrote: > This is a very long reply to several emails. > > On Thu, Jun 27, 2024 at 5:45 PM Jim Winstead <j...@trainedmonkey.com> wrote: >> __ >> The angle I am coming at this from is improving the developer experience >> around "packages" or "modules" or whatever you want to call them, and so >> much of this proposal doesn't seem to be about that. >> > > Ok, first problem - not a proposal really, but a ramble trying to get to a > proposal. Before I made the first post the idea was knocking around in my > head and wouldn't go away, so I just stream of consciousness listed what's > going through my head. That leads to the second point you made. > >> >> I could have made that point in other ways, and I'm sorry that my first >> attempt came off as insulting. It really concerned me when I already saw >> discussion about taking this off-list and going into the weeds on technical >> details when the problem that is being addressed by this proposal is >> extremely unclear to me. > > It is unclear even to me. Perhaps I shouldn't have posted out something this > half baked. That said, pruning off large sections of language functionality > is a distraction. For now let's just note that it is a possibility to improve > the language this way afforded by the fact that import would be new way of > bringing scripts in. Could isn't should. Also, at the moment again it's a > distraction. Let's focus down on how code is imported. > > First though, a history review, partially to get this straight in my own head > but hopefully of use for those following along. Why? Knowing how we got we > are is important to some degree to chart a way forward. > > PHP started as a template engine. By modern standards, and compared to the > likes of twig, it's a very bad template engine, but that doesn't really > matter because it's evolved into a programming language in it's own right > over the last nearly 20 years.
How do you think twig works, exactly? You should probably check it out, because templates compile down to regular PHP templates -- at least it did the last time I looked at it a few years ago. How do you think emails are templated by php code? How do you think anything is output? By either "echo" or ?> content <?php, or fwrite/file_put_contents Without that, there is literally no purpose to php code (or any code). > > Include, include_once, require, and require_once have been around since the > beginning as the way to splice code files together. The behavior of these > statements calls back to PHP's origin as a template engine as they do things > similar mechanisms like JavaScript's import do not do (and for that matter, > their equivalents in C# and Java). Their scope behavior is very different > from import mechanisms in other languages, as they see the variables in the > scope of the function they were invoked from or the global scope when called > from there. Their parsing can be aborted early with a return. They can > return a value, which is quite unusual to be honest. None of this is bad per > se, but it is different and the question arises is it necessary. How do you think javascript import works, exactly? They load a file which returns a value via export. There is nothing inherently wrong with requires/includes, it's literally required by every language via some mechanism or another (C's include statements, go's go.mod file, javascripts import/package.json, C#'s project config, etc). There's no magical thing here, just abstractions and different levels of it. > > One artifact of their behavior that is bad in my opinion is that they start > from the standpoint of being text or html files. Every single language starts with a text file... There's nothing inherently special about the bytes in any source code file and they only have meaning due to creating a parser that can make sense of the stream of bytes. The fact that they also have meaning to humans is what makes it source code and not object code/byte code. > If the included file has no PHP tags then the contents get echoed out. If > there are no output buffers running this can cause headers to be set and fun > errors to be had. So they can't be used to create files that can only echo > explicitly (that is, a call to the echo statement or the like). For headers, this is largely up to the SAPI (the program that executes the PHP code, eg, frankenphp, php-fpm, mod-cgi, roadrunner, etc) and the fact that most SAPIs want to be able to run existing code where developers have certain expectations of behavior. FrankenPHP did a little something different with the support of the 103 status code which isn't supported in any other SAPI (AFAIK). The CLI sapi doesn't output any headers whatsoever. As far as PHP opening tags go... I don't even notice it. They're there, just like the "package" declaration on the top of every one of my Go files. > > Fast forward a bit - PHP 5.3, and the introduction of namespaces were > introduced to deal with the overloaded symbol tables. They are a bit a > hotwire as (if I'm not mistaken, it's been a couple years since I read the > discussion on it) they just quietly prepend the namespace string in front of > the name of all new symbols declared in the namespace for use elsewhere. As a > result, PHP namespaces don't do some of the things we see in the namespaces > of other languages (looking at Java and C# here). For example, privacy > modifiers within a namespace aren't a thing. This would be nice to have ... maybe. But namespace have been around, what, 10-15 years? I think if someone wanted to "fix" it, it would have been fixed by now. > > Very quickly after PHP 5.3 released autoloaders showed up. At some point > support for multiple autoloaders was added. Several schema were added, PSR-4 > won out, and composer showed up to leverage this. Composer is based on NPM, > even to the point where json is used to configure it, and the composer.json > file is fairly close to npm's package.json file even now. It's a userland > solution, but to my knowledge WordPress is the only widely used PHP > application out there that doesn't use it directly (there is a Composer > Wordpress project). WordPress predates composer et. al., by more than 10 years (if you count the B2 code it was forked from). Why would it use it? From working at Automattic (I left a couple of years ago, and this is merely what I saw as an observer, I wasn't closely involved with any of the open-source side), there was a bit of a push to make it happen as it looked like Composer would be around for awhile, but then there was talk about an "official" loader/thing from php itself and I think they'd rather use that instead. When you have a project that has literally been around decades, you don't change out your whole system on the whims of what is fashionable at the time; you either innovate or wait and see what becomes standard. Composer has only been around 50% of the time WordPress has been around now; and it didn't start out as immediately popular. > Before composer, and before namespaces there was PECL. Composer has eclipsed > it because PECL has the limitation of being server-wide. It never really > caught on in the age of virtual hosting with multiple PHP sites running on > one box. Today we have Docker, but that didn't help PECL make a comeback > because by the time docker deployment of PHP sites became the norm composer > had won out. Also, composer library publishing is more permissive than PECL. > I'll stop here lest this digress into a Composer v PECL discussion - suffice > to say stabs a bringing code packages into PHP isn't a new idea, and a survey > of what's been done before, what was right about those attempts and what was > wrong needs to be considered before adding yet another php package system > into the mix. I don't think PECL and Composer have much in common... at all. Like they are not even comparable, and it is still the best way to install extensions (in fact, it is the only way in a docker container AFAIK) on a self-compiled php. > The main influence of composer and autoloaders for preparing packages is that > PHP has become far more Object Oriented than it was before. Prior to PHP 5.3 > object oriented programming was a great option, but since autoloaders cannot > bring in functions (at least not directly, they can be cheated in by bundling > them in static classes which are all but namespaces) the whole ecosystem has > become heavily object oriented. require/include still works fine, or using the "file" key on the autoloader in composer.json. I don't find most of these "problems" actually valid. There is some merit to the conclusions, but the premise feels shaky. — Rob
