Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121484
Message-ID: <ED1ED859-FC81-442D-9A30-EE8D0C639FFD@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D0F42473-3041-4198-A53F-14BBF92787A1"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.4\))
Date: Fri, 27 Oct 2023 06:25:25 -0400
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: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_D0F42473-3041-4198-A53F-14BBF92787A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Oct 26, 2023, at 3:23 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=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. =20

Curious, how do you define a "full class-like construct" in this =
context?  Anything more than autoloading? =20

And would autoloading actually require something to be a "full =
class-like construct," or could it not be something lighter weight =
(assuming full class-like constructs are not than just autoloading?)

> 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.


Straw man proposal:

When PHP recognizes a symbol in the context it would expect a type yet =
PHP does not recognize that type, PHP could use the existing autoload =
mechanism to determine files and directories in which those types might =
be located. This would address namespaces, I believe

Then, following PSR 4 is could attempt to autoload via a file of the =
same name.  If there are types and classes, interfaces, traits and/or =
enums with that same name they would all need to be contained in that =
same named file, much as it currently works.=20

Of course that would require one .PHP file per type which as you mention =
would not be ideal.

So instead, a new PSR could be created to extend PSR 4 to add =
type-specific considerations. For example, when the type passed in is =
"Foo" it could first look for `/~types.php` and load it but it that did =
not work then it could look for `/~types/Foo.php`.  I picked the tilde =
(~) since it cannot be part of a valid namespace of class name so no =
backward compatibility concerns.

If the type name passed to the autoloader is `Foo/Bar` then it could =
look in `/~types.php` first, if not there then `/Foo/~types.php` and if =
not there, then `/~types/Foo/Bar.php`.  I picked the tilde (~) since it =
cannot be part of a valid namespace of class name so no backward =
compatibility concerns.

Having a single `~types.php` per namespace would let developers put all =
their types for that namespace there, if that is what they prefer. Or =
they could pull all types in the root's `/~types.php`.  Or they could =
create a file for each, whichever their preferences.

I am envisioning a new `type_exists()` function would be required.

Even better would be to add an additional optional parameter $type to =
my_custom_autoloader_new() which could either pass in a numeric for some =
new predefined constants like PHP_AUTOLOAD_CLASS=3D1, =
PHP_AUTOLOAD_INTERFACE=3D2, etc., or just a string like "class", =
"interface", etc.

Based on that idea, such an autoloader might look like this:

function my_custom_autoloader_new( $name, $type ) {
    $dir =3D __DIR__ . '/includes';
    switch ($type) {
       case PHP_AUTOLOAD_TYPE:
          $file =3D sprintf("%s/~types.php", $dir);
          if ( file_exists( $file ) ) {
             require_once $file;
          }
          if (type_exists($name)) {
             return;
          }
          $file =3D sprintf( "%s/~types/%s.php", $dir, $name );
       default:
          $file =3D sprintf("%s/%s.php", $dir, $name);
    }
    if ( file_exists( $file ) ) {
       require_once $file;
    }
}
=20
> So any type alias proposal would need to sort out the above =
"definition problem" in a way that's generally acceptable.  That's been =
the hold up for 3 years, I think.

The above is potentially one way to skin that cat. =20

Anyway, I'm sure there will be lots of opinions on this, so bikeshed =
away.

-Mike


--Apple-Mail=_D0F42473-3041-4198-A53F-14BBF92787A1--