So, who is going to help with the implementation :)

On Saturday, October 28, 2023, Alexandru Pătrănescu <dreal...@gmail.com>
wrote:

> Hey,
>
> So actually while reading this:
>
> On Fri, Oct 27, 2023 at 11:42 PM Oladoyinbo Vincent <oladoyin...@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
>

Reply via email to