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 <[email protected]> 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