Re: [PHP-DEV] Re: Basic Type Alias
Hello,
I took the time to read you. Very interesting discussion.
I'm also interested in the type definition.
Because these two functions are equivalent:
> function foo(?int $baz) {}
> function foo(null|int $baz) {}
We could imagine a personalized null-safety type.
> typedef Refutable as null|false|NAN|INF; // I'm not sure that NAN and INF
are types
> typedef UserId as Refutable ! int;// Refutable is the type of null-safety
> function zoo(UserId $id) {} // $id is (int)
> function noo(?UserId $id) {}// $id is (null|false|NAN|INF|int)
Do you plan to use enum cases as type ?
enum MyEnum{ case Foo = 1; case Zoo = 2;}
use enum MyEnum::Foo as MyFoo;// syntaxe error
typedef Mamamia MyFoo|MyEnum::Zoo
[PHP-DEV] Re: Basic Type Alias
I have been so busy lately, which gave me no time to work on the type alias
implementation. but I will be happy if anyone can volunteer/help in
implementing this feature so that it can be introduced in PHP 8.4 or 9.0,
as this will help optimise a lot of people and codebase out there.
On Monday, October 30, 2023, Larry Garfield wrote:
> On Sun, Oct 29, 2023, at 9:52 PM, Jorg Sowa wrote:
> > I really like the idea and I would love to see it in PHP. I'm wondering
> > however, what would be the scope of the feature and how complex would be
> > designed type system. Examples I saw in this thread could be easily
> > replaced with union and intersection types (i.e. numeric as int|float).
> In
> > my opinion, there is a little benefit implementing in this shape making
> the
> > PHP core more complex.
> >
> > The two use cases of user defined types in PHP which would benefit a lot
> > IMO, would be:
> > 1. Typed arrays similar to Typescript.
> > 2. Semantic types which would increase the security of systems. Example:
> > type UserId = int;
> >
> > function setUserId_1(int $userId){}
> >
> > function setUserId_2(UserId $userId){}
> >
> > setUserId_1(5); // OK
> > setUserId_2(5); // TypeError
> >
> > setUserId_1(UserId(5)); // OK
> > setUserId_2(UserId(5)); // OK
> >
> > Kind regards,
> > Jorg
>
> Simple unions are the easiest to talk about in quick examples, but the
> real benefit of type aliases is in other cases, some of which they would
> enable.
>
> Example:
>
> I have a real parameter defined in my attributes library like this:
>
> \ReflectionProperty|\ReflectionMethod|\ReflectionClassConstant $subject
>
> And it appears several times, I believe. That would definitely be nicer
> if simplified to an alias.
>
> Example:
>
> There's general consensus that callable types would be beneficial:
> callable(RequestInterface, string): string or similar. But inline, that
> gets long and complicated fast. Type aliases would allow simplifying that
> to
>
> type callable(RequestInterface, string): string as PropertyRetriever
>
> function foo(PropertyRetriever $c) { ... }
>
> Example:
>
> As in the above example, type aliases serve as documentation for callables
> or complex types, explaining what that complex ruleset actually means,
> semantically.
>
> Example:
>
> If generics or typed arrays ever happen, they'd probably be useful here,
> too.
>
> Note that using type aliases in a required-fashion is a different matter,
> and potentially not feasible. Free standing variables are untyped, which
> means setUserId(UserId $id) could not require a UserId, because there's no
> way to define a variable as being a UserId, not an int. While I can
> definitely see a value in that kind of restriction, in practice I don't
> think PHP is capable of it without vastly larger changes.
>
> --Larry Garfield
>
--
Best Regards,
O. Vincent
Re: [PHP-DEV] Re: Basic Type Alias
File-based are the worst. Let the types be attached to namespaces. As we have autoloaders, everyone is free to load them however they want (PSR-4, file, custom autoloader, whatever). Best regards, Erick Em seg., 30 de out. de 2023 às 08:34, G. P. B. escreveu: > On Sun, 29 Oct 2023 at 20:36, Robert Landers > 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 >
Re: [PHP-DEV] Re: Basic Type Alias
On Sun, 29 Oct 2023 at 20:36, Robert Landers 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
Re: [PHP-DEV] Re: Basic Type Alias
On Sat, Oct 28, 2023 at 10:29 PM Alexandru Pătrănescu
wrote:
>
> Hey,
>
> So actually while reading this:
>
> On Fri, Oct 27, 2023 at 11:42 PM Oladoyinbo Vincent
> wrote:
>
> > 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;
> >
> > }
> >
> >
> I came up with an idea:
>
> In php we don't have inner/nested classes, like in Java.
> But maybe at some point we could have. An inner class would help with
> avoiding some extra files and autoloading, especially when that class would
> be needed as private.
>
> Coming back to types, what if a type would be allowed to be defined on the
> class level?
> It would solve the autoloading problem as it would be loaded together with
> the class.
> And I guess that in real-life, complex types are usually related to some
> code using them, so I expect that identifying a class where the type to be
> placed would not be hard.
> And even if it would be difficult, There can always be a class named Types
> that would have only type definitions.
>
> An example would look like this:
>
> namespace My\App;
> class Types {
> public type Numeric: int|float;
> }
>
> And it could be used with:
>
> use My\App\Types.Numeric;
> function castNumericToFloat(Numeric $number): float {
> return (float)$number;
> }
>
> or
>
> use My\App\Types;
> function castNumericToFloat(Types.Numeric $number): float {
> return (float)$number;
> }
>
> or by using an import alias, of course.
>
> Maybe we can use this construct, along with allowing a type to be defined
> in a normal way, a way that would not permit autoloading.
> However, a way that would better fit code that is procedural and it can be
> loaded in the same functions.php that some projects use.
>
> Allowing inner "types" on classes might be a bit more complex that I can
> ever evaluate.
> But it might open the door for inner classes and there are nice constructs
> that can be built using this.
>
> Regards,
> Alex
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.
Robert Landers
Software Engineer
Utrecht NL
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Basic Type Alias
So, who is going to help with the implementation :)
On Saturday, October 28, 2023, Alexandru Pătrănescu
wrote:
> Hey,
>
> So actually while reading this:
>
> On Fri, Oct 27, 2023 at 11:42 PM Oladoyinbo Vincent
> wrote:
>
>> 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;
>>
>> }
>>
>>
> I came up with an idea:
>
> In php we don't have inner/nested classes, like in Java.
> But maybe at some point we could have. An inner class would help with
> avoiding some extra files and autoloading, especially when that class would
> be needed as private.
>
> Coming back to types, what if a type would be allowed to be defined on the
> class level?
> It would solve the autoloading problem as it would be loaded together with
> the class.
> And I guess that in real-life, complex types are usually related to some
> code using them, so I expect that identifying a class where the type to be
> placed would not be hard.
> And even if it would be difficult, There can always be a class named Types
> that would have only type definitions.
>
> An example would look like this:
>
> namespace My\App;
> class Types {
> public type Numeric: int|float;
> }
>
> And it could be used with:
>
> use My\App\Types.Numeric;
> function castNumericToFloat(Numeric $number): float {
> return (float)$number;
> }
>
> or
>
> use My\App\Types;
> function castNumericToFloat(Types.Numeric $number): float {
> return (float)$number;
> }
>
> or by using an import alias, of course.
>
> Maybe we can use this construct, along with allowing a type to be defined
> in a normal way, a way that would not permit autoloading.
> However, a way that would better fit code that is procedural and it can be
> loaded in the same functions.php that some projects use.
>
> Allowing inner "types" on classes might be a bit more complex that I can
> ever evaluate.
> But it might open the door for inner classes and there are nice constructs
> that can be built using this.
>
> Regards,
> Alex
>
Re: [PHP-DEV] Re: Basic Type Alias
Hey,
So actually while reading this:
On Fri, Oct 27, 2023 at 11:42 PM Oladoyinbo Vincent
wrote:
> 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;
>
> }
>
>
I came up with an idea:
In php we don't have inner/nested classes, like in Java.
But maybe at some point we could have. An inner class would help with
avoiding some extra files and autoloading, especially when that class would
be needed as private.
Coming back to types, what if a type would be allowed to be defined on the
class level?
It would solve the autoloading problem as it would be loaded together with
the class.
And I guess that in real-life, complex types are usually related to some
code using them, so I expect that identifying a class where the type to be
placed would not be hard.
And even if it would be difficult, There can always be a class named Types
that would have only type definitions.
An example would look like this:
namespace My\App;
class Types {
public type Numeric: int|float;
}
And it could be used with:
use My\App\Types.Numeric;
function castNumericToFloat(Numeric $number): float {
return (float)$number;
}
or
use My\App\Types;
function castNumericToFloat(Types.Numeric $number): float {
return (float)$number;
}
or by using an import alias, of course.
Maybe we can use this construct, along with allowing a type to be defined
in a normal way, a way that would not permit autoloading.
However, a way that would better fit code that is procedural and it can be
loaded in the same functions.php that some projects use.
Allowing inner "types" on classes might be a bit more complex that I can
ever evaluate.
But it might open the door for inner classes and there are nice constructs
that can be built using this.
Regards,
Alex
Re: [PHP-DEV] Re: Basic Type Alias
On 27.10.2023 22:42, Oladoyinbo Vincent wrote:
```php
namespace Package;
typedef MyTypes {
type Numeric: int|float|null;
type Chars: string|null;
type Result: bool|null;
}
```
```php
use Package\MyTypes;
class Hello {
use MyTypes;
public function A(Numeric $id, Chars $message): Result
{
}
}
```
Your typedef is essentially just a trait. One new keyword less. What
would be missing is direct access to type.
If we indeed allow type inside a class/trait, then natural syntax
becomes the one used for const/var.
I think your syntax 2 is the worst anyway. Syntax 3 (use-as) will not
gonna fly as we already have use-as in a conflicting use for classes,
unless you change it to "use type string|null as NullableString".
I think Syntax 1 makes most sense, especially considering a case of long
list of "subtypes" that could be class names with namespace.
Types should also support visibility (public|protected|private) when in
class/trait context.
--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] 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 wrote:
> > On Oct 26, 2023, at 3:23 PM, Larry Garfield
> 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.
>
