On Thu, Oct 26, 2023 at 4:23 PM Larry Garfield <la...@garfieldtech.com> wrote:
> On Thu, Oct 26, 2023, at 6:37 AM, Oladoyinbo Vincent 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
