On Sun, 29 Oct 2023 at 20:36, Robert Landers <landers.rob...@gmail.com> wrote:
> My personal opinion is that file-based type aliases would be the best. > It solves an immediate problem while introducing a problem most people > will never have (needing to reuse the type aliases elsewhere). It > allows them to be used in functions and classes, while also making > code more readable but not opaque outside the file. For example, if > there is a type called BigNumber that was an alias of > GMP|int|float|string, outside the file, knowing the actual types in my > IDE is more useful than "BigNumber" and doesn't require me to dig into > the definition or even agree with the other file's definition of > "BigNumber." I just need to know that I need to pass it one of those > types from my own code. However, reading that file's code, I don't > need to know the intimate details of the aliases to make it more > readable. > > If we find ourselves constantly writing the same type aliases in a > bunch of files, we only need to wait less than a year to implement > "global" (as in, available once include'ed) in the very next version > of PHP. > No, this is actually ridiculous. File based type alias are dumb and I will vote against this. My main motivation to work on function autoloading in the first place was to create a mechanism so that adding a new type autoloader is very easy. As I already find the semantics of one interface per file dumb, let's not make it even more ridiculous of having a single line in a file, especially as a library/project will likely want to declare more than one type. An IDE should very much have no struggle to resolve what the type alias actually resolves too, they already do this with classes and interfaces. And needing to declare every alias in every single file of a project is a ludicrous idea. Best, Gina/George P. Banyard
