> On Oct 26, 2023, at 3:23 PM, Larry Garfield <la...@garfieldtech.com> wrote:
>
> 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.
Curious, how do you define a "full class-like construct" in this context?
Anything more than autoloading?
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.
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=1, PHP_AUTOLOAD_INTERFACE=2, 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 = __DIR__ . '/includes';
switch ($type) {
case PHP_AUTOLOAD_TYPE:
$file = sprintf("%s/~types.php", $dir);
if ( file_exists( $file ) ) {
require_once $file;
}
if (type_exists($name)) {
return;
}
$file = sprintf( "%s/~types/%s.php", $dir, $name );
default:
$file = sprintf("%s/%s.php", $dir, $name);
}
if ( file_exists( $file ) ) {
require_once $file;
}
}
> 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.
Anyway, I'm sure there will be lots of opinions on this, so bikeshed away.
-Mike
