Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117420
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>
 <CAKWdMui5cduh9MtQ1tv+N-Q6g+isfptNYmnpS3C0cm=yCjd_OQ@mail.gmail.com> <2abc84a5-0ca2-9431-0585-d3d6ee3df456@processus.org>
In-Reply-To: <2abc84a5-0ca2-9431-0585-d3d6ee3df456@processus.org>
Date: Thu, 24 Mar 2022 13:50:50 -0500
Message-ID: <CAESVnVpLuOXYGSy5-N_-KGtJqwWvd-STKSaNuJqT4ma70H50LQ@mail.gmail.com>
To: Pierre <pierre-php@processus.org>
Cc: Mark Niebergall <mbniebergall@gmail.com>, Larry Garfield <larry@garfieldtech.com>, 
	php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ceb80705dafb530b"
Subject: Re: [PHP-DEV] Typed constants revisited
From: pollita@php.net (Sara Golemon)

--000000000000ceb80705dafb530b
Content-Type: text/plain; charset="UTF-8"

On Thu, Mar 24, 2022 at 10:20 AM Pierre <pierre-php@processus.org> wrote:

>
> That was exactly my point: the type could simply implicitely be the one
> of the original value.
>
>
That works when the initial value is a literal, but what about when it's
another cost?

class Foo {
  const BAR = Baz::BAR;
  const BLING = MY_QUX;
}

What type are Foo::BAR and Foo::BLING?  Suddenly these constants have
dependent type and resolving it becomes less trivial.

Also, what happens when this code is originally written when MY_QUX is a
string, but then gets redefined (because it lives in another library we
don't control).

Allowing the author to put an explicit type removes all that uncertainty.

-Sara

--000000000000ceb80705dafb530b--