Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121478
MIME-Version: 1.0
References: <CAHXoPRtjsPzgpYnhB05hjdZo6Q-MDr4TUGbn9LQ77-hKVTCZOA@mail.gmail.com>
 <e94b0021-b18d-4c48-8764-6d4909142b26@app.fastmail.com> <CADK1yXJhYc7hxa3-oLYqk0+hNy1FPFwUfRAD+Qej3Op1P3jAyg@mail.gmail.com>
 <CAGS0MVB4KajF72G=A+4fb1=-y3zk6fv7A7YpX_waZONzNV7BXw@mail.gmail.com>
In-Reply-To: <CAGS0MVB4KajF72G=A+4fb1=-y3zk6fv7A7YpX_waZONzNV7BXw@mail.gmail.com>
Date: Fri, 27 Oct 2023 02:53:13 +0100
Message-ID: <CAHXoPRsoDB1oxSbVLewxJ4-PkZzYQsoqLKyoqxYNW+YMXjcf6A@mail.gmail.com>
To: Erick de Azevedo Lima <ericklima.comp@gmail.com>
Cc: Deleu <deleugyn@gmail.com>, Larry Garfield <larry@garfieldtech.com>, 
	php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004846080608a8f491"
Subject: Re: [PHP-DEV] Basic Type Alias
From: oladoyinbov@gmail.com (Oladoyinbo Vincent)

--0000000000004846080608a8f491
Content-Type: text/plain; charset="UTF-8"

Since there may be need for reusability, I feel it can have this kind of
structure:

// File: A.php

```

namespace A;

typedef TypeLists {

    type Msg = string|null;

    type Numeric = int|float;

    type MyClass = \Package\Test|\Package\Db;

}

```

// file: B.php

```

declare(strict_types=1);

use A\TypeLists;

class Test1 {

    use TypeLists;

    public function greet(Msg $message): Msg {
        // ...
    }

}


$init = new Test1;

// it triggers TypeError when strict types is declared
$init->greet(1); // TypeError

```

And for local usage only:

```php

typedef T = int|string|null;

// or

type T = string|int|null;



$msg = fn (T $message): T => $message;

echo $msg;

```

On Fri, 27 Oct 2023, 12:51 am Erick de Azevedo Lima, <
ericklima.comp@gmail.com> wrote:

> I'll use it a lot if they'll be namespaced. It avoids name-collision using
> the existing ecosystem and we already use lots of "uses" in our codes.
> When Enums came to the party, they came namespaced as traits, classes and
> interfaces. The last 2 represent types, concrete and abstract.
> User defined types are nothing more than types, so I think the way to gois
> to keep it namespaced as well.
>
> About the type compatibility, covariance and contravariance, let's say I
> define some type inside my package:
>
> // File: C1.php =>  My package code
>
> namespace N1;
>
> typedef MyString =
> string|Stringable|\Symfony\Component\String\UnicodeString
> ;
> typedef MyBool = null|bool;
> typedef BigNumeric = int|float|\Brick\Math\BigNumber;
>
> class C1
> {
>     protected function myQuestionableFunction(MyString $str1): MyBool
>     {
>         //...
>     }
>
>     protected function myQuestionableFunction2(null|C1 $str1):
> ScalarNumeric
>     {
>         //...
>     }
> }
>
> // File: C2.php => On the project of those who are using my package
>
> namespace N2;
>
> typedef ScalarNumeric = int|float;
> typedef Falsy = null|false;
>
> class C1 extends C2
> {
>     protected function
>
> myQuestionableFunction(string|Stringable|\Symfony\Component\String\UnicodeString
> $str1): Falsy
>     {
>         //...
>     }
>
>     protected function myQuestionableFunction2(Falsy|C1 $str1):
> ScalarNumeric
>     {
>         //...
>     }
> }
>
> I propose that this code should be valid code, because, in the end, these
> *typedef's*, are just synonyms.
>
> *Note:* By the way, I propose to use the C/C++ keyword, which is *typedef*
> and
> dropping the syntax* "type MyType = [string, null];",*
> which differs too from how typehints are used and do not add any benefits
> *.*
>
> --
> Erick
>

--0000000000004846080608a8f491--