Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121489
MIME-Version: 1.0
In-Reply-To: <ED1ED859-FC81-442D-9A30-EE8D0C639FFD@newclarity.net>
References: <CAHXoPRtjsPzgpYnhB05hjdZo6Q-MDr4TUGbn9LQ77-hKVTCZOA@mail.gmail.com>
 <e94b0021-b18d-4c48-8764-6d4909142b26@app.fastmail.com> <ED1ED859-FC81-442D-9A30-EE8D0C639FFD@newclarity.net>
Date: Fri, 27 Oct 2023 13:42:07 -0700
Message-ID: <CAHXoPRtSEBPEFf1FrkwfqK_keFd7crvACBpm23etZ0ajNz6DDg@mail.gmail.com>
To: Mike Schinkel <mike@newclarity.net>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ca2a0d0608b8b831"
Subject: Re: Basic Type Alias
From: oladoyinbov@gmail.com (Oladoyinbo Vincent)

--000000000000ca2a0d0608b8b831
Content-Type: text/plain; charset="UTF-8"

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
>
>

--000000000000ca2a0d0608b8b831--