Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117408
MIME-Version: 1.0
References: <CAKWdMuh=qmE1==KnqqPX-yeNh5oObxFrVcaZ_LNUW+rFzqbN-A@mail.gmail.com>
 <76c399cb-fb29-4583-a212-8eb69740c96b@www.fastmail.com>
In-Reply-To: <76c399cb-fb29-4583-a212-8eb69740c96b@www.fastmail.com>
Date: Wed, 23 Mar 2022 16:55:37 -0600
Message-ID: <CAKWdMuiGK3-090QYB6UhgjUAhhoCjS78B9VbCVFqxMVYqqkO7w@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006b661b05daeaa1e5"
Subject: Re: [PHP-DEV] Typed constants revisited
From: mbniebergall@gmail.com (Mark Niebergall)

--0000000000006b661b05daeaa1e5
Content-Type: text/plain; charset="UTF-8"

On Wed, Mar 23, 2022 at 4:10 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> On Wed, Mar 23, 2022, at 1:54 PM, Mark Niebergall wrote:
> > Hello All,
> >
> > In June 2020, Benas Seliuginas emailed this list (
> > https://externals.io/message/110755#110755) to gauge interest in typed
> > constants. An RFC (https://wiki.php.net/rfc/typed_class_constants) was
> > started and had an accompanying PR (
> https://github.com/php/php-src/pull/5815).
> > At the time, Nikita Popov supported it for overall language consistency,
> > and Sebastian Bergmann +1'd it for overall language consistency as well.
> > The PR has since been closed without being merged, and the idea hasn't
> > progressed since.
> >
> > I'd like to revisit the concept, gauge current interest, and pick the
> > concept and work back up. Any more discussion items for or against the
> idea?
> >
> > I'm willing to do the work to pick it up where it was left off and get an
> > RFC proposed through the normal process, and a working PR. This is my
> first
> > foray into the PHP RFC process, and C code is not my forte, but I'll take
> > it on. If anyone would be willing to pair/mentor/co-author with me,
> please
> > let me know. Either way, I'll plan to work on it.
> >
> > This is the first of several concepts I have been tinkering with and
> seeing
> > practical uses for. The next phase of work with different RFC would take
> > this further with const inheritance, where const type must match.
> >
> > - Mark
>
> Is there a benefit to it other than "well everything else has types now,
> so..."?  Even if it's esoteric, like in reflection-based meta programming?
> (I've been dabbling too much in that lately. :-) )  "Everything else does"
> isn't a compelling argument for me, but there may be others I'm not
> thinking of.
>
> --Larry Garfield
>

Larry and Internals,

To the benefits!

On its own, typing class constants does help align them with other things
like typed class properties, typed arguments, and method return types.
There will come additional benefits though, and this would be phase 1.
Phase 2 would be to introduce typed constants to be set by extending or
implementing classes. Combining the two features would lead to better
defined and usable class constants.

For example, an interface could be:

```
interface DbTable
{
    public const string TABLE_NAME;
}
```

Which would then be implemented as:

```
class UserTable implements DbTable
{
    public const string TABLE_NAME = 'user';
}
```

Thus ensuring `TABLE_NAME` is always set, and always returns a `string`
type. See https://docs.laminas.dev/laminas-db/table-gateway/ for a
real-world framework example where this feature _could_ be used.

Another example I often see in my projects could be used with a similar
example:

```
abstract class Bird
{
    public const bool CAN_FLY;
    public const string FAMILY;
    public function canFly(): bool
    {
        return self::CAN_FLY;
    }
}
final class EmperorPenguin extends Bird
{
    public const bool CAN_FLY = false;
    public const string FAMILY = 'penguin';
}
```

In this case, one could instead use typed class properties, but it feels
improper since the values are static and unchanging. Immutability is a work
around to this when implemented properly. This would simplify the solution
while ensuring values remain unchanged.

- Mark



>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--0000000000006b661b05daeaa1e5--