Newsgroups: php.internals,php.internals
Path: news.php.net
Xref: news.php.net php.internals:121479 php.internals:121480
Message-ID: <031056A8-8F22-439F-9B77-75929798D2DD@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_48773001-4E95-48E4-94D1-453DFA33D1BD"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Date: Fri, 27 Oct 2023 09:45:18 +0200
In-Reply-To: <e94b0021-b18d-4c48-8764-6d4909142b26@app.fastmail.com>
Cc: php internals <internals@lists.php.net>
To: Larry Garfield <larry@garfieldtech.com>
References: <CAHXoPRtjsPzgpYnhB05hjdZo6Q-MDr4TUGbn9LQ77-hKVTCZOA@mail.gmail.com>
 <e94b0021-b18d-4c48-8764-6d4909142b26@app.fastmail.com>
Subject: Re: [PHP-DEV] Basic Type Alias
From: claude.pache@gmail.com (Claude Pache)

--Apple-Mail=_48773001-4E95-48E4-94D1-453DFA33D1BD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 26 oct. 2023 =C3=A0 21:23, Larry Garfield <larry@garfieldtech.com> =
a =C3=A9crit :
>=20
> App-wide aliases run into the autoloading problem.  If the engine runs =
across the add() function above, and "numeric" isn't defined, what can =
it do?  Currently, all it can do is trigger autoloading, which only =
works for class-ish constructs (class, interface, trait, enum).  Making =
type aliases a full class-like construct seems... weird, and =
over-engineered.  But if not, how do we autoload them?  And if they do =
autoload somehow, does that mean we end up with a bunch of files with a =
single `type` line in them?  That seems not-good.  You also then have to =
ask how they interact with namespaces.
>=20
> So far no one seems to like my idea of "composer has a files block, =
PHP has a preloader, they're small, so who the hell cares about =
autoloading, just greedily load them and move on with life", even though =
I think that's the best answer. :-)

Hi,

=E2=80=9CAutoloading=E2=80=9D does not mean (and has never meant) =E2=80=9C=
one file per class-like construct=E2=80=9D; even if it is the most =
customary strategy (and the one consecrated by PSR), it is by no means =
the only one.

Proof of concept: With the following autoloader, at the first time the =
compiler needs the definition of some class-like symbol under the =
FooBits\Acme\Type namespace, all symbols under that namespace are loaded =
together:

```php
spl_autoload_register(function ($class) {
    if (str_starts_with($class, 'FooBits\\Acme\\Type\\')) {
        // we have conventionally put all types defined by our library =
under this namespace,
        // and there are all defined together in the following file:
        require 'vendor/foobits/acme/src/types.php';
    }
    elseif (str_starts_with($class, 'FooBits\\Acme\\')) {
        // for other symbols we use the boring psr-4 convention
        require 'vendor/foobits/acme/src/' . str_replace('\\', '/', =
substr($class, 13)) . '.php';
    }
});
```

I think that treating the type aliases as class-like *names* for the =
purpose of naming and autoloading (without giving my opinion whether =
they are class-like *constructs* for some definition of =E2=80=9Care=E2=80=
=9D) is a reasonable approach, and =
autoloading/preloading/whatever-loading-strategy ought to be treated as =
an orthogonal (non-)issue.

=E2=80=94Claude=

--Apple-Mail=_48773001-4E95-48E4-94D1-453DFA33D1BD--