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 <[email protected]> wrote:
> > On Oct 26, 2023, at 3:23 PM, Larry Garfield <[email protected]>
> 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
>
>
