On Sat, Oct 28, 2023 at 10:29 PM 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
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
