Re: Basic Type Alias

So, we have to discuss and conclude on the best syntax to use for the Type Alias: Syntax 1: ```php type T = int|string|null; ``` Syntax 2: ```php type T: int|string|null; ``` Syntax 3: ```php use int|string|null as T; ``` And also, we need a function to check of type exist, maybe type_exists() will be a great choice :). And also, in order to group and namespace the Type Alias, i suggest we use typedef, like i specify in my last message, it will be like this: File A.php: ```php namespace Package; typedef MyTypes { type Numeric: int|float|null; type Chars: string|null; type Result: bool|null; } ``` File B.php: ```php declare(strict_types=1); use Package\MyTypes; class Hello { use MyTypes; public function A(Numeric $id, Chars $message): Result { // get the value echo Numeric::value; // int|float|null } } ``` Well, it's just the round up of every features listed in this discussion, how is it? I will like to see your thought on this :). Best Regards O. Vincent. On Friday, October 27, 2023, Mike Schinkel <mike@newclarity.net> wrote: > > On Oct 26, 2023, at 3: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. > > 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 > >