Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117414
MIME-Version: 1.0
References: <CAKWdMuh=qmE1==KnqqPX-yeNh5oObxFrVcaZ_LNUW+rFzqbN-A@mail.gmail.com>
 <76c399cb-fb29-4583-a212-8eb69740c96b@www.fastmail.com> <95fb2485-fa60-a107-5fd2-acdcef09bca3@processus.org>
In-Reply-To: <95fb2485-fa60-a107-5fd2-acdcef09bca3@processus.org>
Date: Thu, 24 Mar 2022 09:06:45 -0600
Message-ID: <CAKWdMui5cduh9MtQ1tv+N-Q6g+isfptNYmnpS3C0cm=yCjd_OQ@mail.gmail.com>
To: Pierre <pierre-php@processus.org>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007444f205daf8321d"
Subject: Re: [PHP-DEV] Typed constants revisited
From: mbniebergall@gmail.com (Mark Niebergall)

--0000000000007444f205daf8321d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Pierre,

On Thu, Mar 24, 2022 at 1:04 AM Pierre <pierre-php@processus.org> wrote:

> Le 23/03/2022 =C3=A0 23:10, Larry Garfield a =C3=A9crit :
> > 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
> >
> Hello,
>
> Well I was thinking myself that const being well... constant, and so
> always defined, type could be determined at compile time without the
> need to express it in a verbose way.
>
> PHP doesn't do any static type inference, but in this case, it could be
> done almost for free, am I wrong ? If it was determined at compile time,
> then the type checking on overrides would only be trivial, using the
> parent occurrence value inferred type. My point is that there's no need
> to express the type of a value, the value has already has a type.
>

As a developer, I don't *always* trust other developers implementing my
code. Referring back to the Bird and EmperorPenguin example, the expected
type for `public const bool CAN_FLY;` example MUST be a bool. If it isn't
typed, another developer _could_ incorrectly set `CAN_FLY =3D 1;` or `CAN_F=
LY
=3D 'true';` or even `CAN_FLY =3D 'Y';`. With class constants typed, they w=
ould
get an error if setting it to anything other than a bool `CAN_FLY =3D true;=
`
or `CAN_FLY =3D false;`. This further proliferates into sending the value o=
f
`CAN_FLY` into a typed argument like `protected function
determineModeOfTransport(bool $canFly)` - if the constant is set
incorrectly as a string or integer then more errors can occur.

Typing class constants could also help static code analyzers more easily
determine if there are bugs with unexpected value types being used in code.
Instead of determining the value of the constant, the type of the constant
could be used instead, providing a cleaner tokenized parsing.

So you are correct, the const value does have a value that has a type, but
there is no way to enforce which type the value is or to use const with
inheritance, which is part of the bigger picture here.



>
> Regards,
>
> --
>
> Pierre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--0000000000007444f205daf8321d--