Re: Basic Type Alias

So, who is going to help with the implementation :) On Saturday, October 28, 2023, Alexandru Pătrănescu <drealecs@gmail.com> wrote: > Hey, > > So actually while reading this: > > On Fri, Oct 27, 2023 at 11:42 PM Oladoyinbo Vincent <oladoyinbov@gmail.com> > 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 >