Basic Type Alias

Hi Saki,

I will have to disagree as the convenience doesn't come from the
complexity of union types, rather how many times its used. Its easier to
use ConstantNode in 10 functions vs NodeA|NodeB|NodeC.

Hi,

It seems to me that there is more to lose than gain. I'm afraid that when we look at the signature, we'll be confused as to whether it's a class or a type.

Even if these problems were successfully resolved, I feel that it would only reduce readability. I've never seen a union type complex enough to require an alias.

Regards.

Saki

On Thu, Oct 26, 2023 at 4:23 PM Larry Garfield larry@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. 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.

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. :-)

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.

I'm also not sure why you're mentioning generics at all. Type aliases
would be helpful with generics, but they're also helpful without generics.
They're orthogonal and not especially related. I agree that there's no
reason to wait for generics to add type aliases.

--Larry Garfield

Unless someone else has good points to raise, it sounds like there's a
clear sign that file-based type aliases are not useful for PHP.

With that in mind, the discussion seems to point straight to autoloading. I
think this shows a limitation with PHP Namespaces and Autoloading
capabilities. I really don't want to judge/belittle/speak ill of something
that was first released 14 years ago, which means discussion and planning
had to have happened even earlier than that. Everything was completely
different back then.

What I see today is that PHP Namespaces seem to have succeeded thanks to
Composer and PSR-4. Working without Composer in 2023 doesn't seem like a
reality to me. Maybe I'm biased/young and if this premise is "too wrong"
then everything else I say after this might be discarded.

PHP Namespaces, Composer and PSR-4 can't really recreate the experience
that ESM provides because 1) Namespaces itself aren't tied to file paths
and 2) PHP doesn't have a build process (path aliases, Typescript types).
What Composer and PSR-4 offers is a static build tool that runs once
(composer dump-autoload) and creates namespace-to-folder mapping that can
be used to discover symbols without a continuous build process or a
continuous composer dump-autoload --watch.

Now my question is: Why PHP Namespace limitation SHOULD be a deciding
factor when talking about Type aliases? The problem is there and exists and
is dealt with as best as it can by the union of PHP Namespaces + Composer +
PSR-4. PHP already has a few symbols that require discovery: Class,
Interface, Enum, Traits and they're all tied to autoloading in case they
haven't been discovered yet. If a Type Alias triggers autoloading,
developers are free to:

1- Implement Type Aliases using 1-file-per-type-alias (PSR-4 compatible).
2- Create a single type-to-rule-them-all.php and rely on Composer File
autoload (greedy).
3- Write a custom autoloading function that deals with the problem however
they want.
4- Manually require_once type-aliases files where they know they need to
be used.
5- Not use Type Alias.

To build up on my question, suppose someone one day comes up with a
solution to PHP Namespace problems (that already affects interfaces,
classes, enums and traits). Could Type Alias make it worse enough that such
a hypothetical solution would be rendered impossible because Type Aliases
were introduced in PHP? Does preventing PHP from having Type Aliases that
comply with the current reality of the project benefit the project in any
meaningful way that it will be easier for something in the future to be
made better?

I know it's hard to talk about hypothetical solutions when we don't know
what they are, but I think we can ballpark that interfaces, classes, enums
and traits are important enough that an enhancement to PHP Namespace system
needs to bring enough benefit without a BC break to be voted in. And such
improvement could just as easily take into consideration type aliases as
one extra thing.

Maybe my lack of knowledge on PHP Source code makes me think that Type
Aliases aren't a big deal as they could be and some insight into that could
shed some light into why this is too simplistic thinking. The simplistic
thinking being: Take Namespaces as they were designed 15 years ago and add
Type Aliases into the mix. Back then a solution decoupled from the
filesystem was introduced and a userland autoloading function was the slim
layer that made PHP Namespaces what they are. We can build on top of that
mindset with type aliases. We need a syntax to declare them and an
autoloading userland function to find where they are declared. Everything
else can fall into place as it did before.

I would love it if we could bring up a discussion on proposing changes to
the PHP Namespace system to allow for something more like ESM while
considering we don't have a build system and a hot-reload system, but I'm
just not sure if PHP Type Aliases is where that discussion MUST to happen.

If this line of thought has any merit, a better question would be whether
Type Alias needs a separate autoload function from class/interfaces or a
single autoload is better. I think that's the kind of discussion that would
help Composer/PSR to decide how to expand and improve the PHP Ecosystem to
include handling of Type Aliases.

--
Marco Deleu

Le 26 oct. 2023 à 21:23, Larry Garfield larry@garfieldtech.com a écrit :

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.

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,

“Autoloading” does not mean (and has never meant) “one file per class-like construct”; 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:

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 “are”) is a reasonable approach, and autoloading/preloading/whatever-loading-strategy ought to be treated as an orthogonal (non-)issue.

—Claude

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

I really like the idea and I would love to see it in PHP. I'm wondering
however, what would be the scope of the feature and how complex would be
designed type system. Examples I saw in this thread could be easily
replaced with union and intersection types (i.e. numeric as int|float). In
my opinion, there is a little benefit implementing in this shape making the
PHP core more complex.

The two use cases of user defined types in PHP which would benefit a lot
IMO, would be:

1. Typed arrays similar to Typescript.
2. Semantic types which would increase the security of systems. Example:
   type UserId = int;

function setUserId_1(int $userId){}

function setUserId_2(UserId $userId){}

setUserId_1(5); // OK
setUserId_2(5); // TypeError

setUserId_1(UserId(5)); // OK
setUserId_2(UserId(5)); // OK

Kind regards,
Jorg

Simple unions are the easiest to talk about in quick examples, but the real benefit of type aliases is in other cases, some of which they would enable.

Example:

I have a real parameter defined in my attributes library like this:

\ReflectionProperty|\ReflectionMethod|\ReflectionClassConstant $subject

And it appears several times, I believe. That would definitely be nicer if simplified to an alias.

Example:

There's general consensus that callable types would be beneficial: callable(RequestInterface, string): string or similar. But inline, that gets long and complicated fast. Type aliases would allow simplifying that to

type callable(RequestInterface, string): string as PropertyRetriever

function foo(PropertyRetriever $c) { ... }

Example:

As in the above example, type aliases serve as documentation for callables or complex types, explaining what that complex ruleset actually means, semantically.

Example:

If generics or typed arrays ever happen, they'd probably be useful here, too.

Note that using type aliases in a required-fashion is a different matter, and potentially not feasible. Free standing variables are untyped, which means setUserId(UserId $id) could not require a UserId, because there's no way to define a variable as being a UserId, not an int. While I can definitely see a value in that kind of restriction, in practice I don't think PHP is capable of it without vastly larger changes.

--Larry Garfield