Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120263
MIME-Version: 1.0
References: <CAPzBOBPQzV=EfYgWL50-mEkjjDOua1brbLyNJ3T89Og+HuUkfA@mail.gmail.com>
 <CA+kxMuT4S9aGfGpxLSaiR3x9hUiZ_N=EbEDh=fYDvdacjkE7cg@mail.gmail.com>
In-Reply-To: <CA+kxMuT4S9aGfGpxLSaiR3x9hUiZ_N=EbEDh=fYDvdacjkE7cg@mail.gmail.com>
Date: Sat, 13 May 2023 17:58:08 +0200
Message-ID: <CAPzBOBMnFh-8EgRprFzP0LErjN39JvQZ6vO6PJP9FwMfC8OrYA@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] [Discussion] nameof
From: landers.robert@gmail.com (Robert Landers)

> Can you provide more details on what the error conditions are? I can
> see 'non-existent static variable' and 'non-existent variable', are
> there others?

Absolutely! I'll add it to the RFC later tonight, but the gist is that
it would be exactly the same as if you were to call any function with
something that doesn't exist.

> > An exception model was considered, however, the author believes that
> > it would break the concept of =E2=80=9Cusing nameof wherever a string c=
ould
> > be used=E2=80=9D and wouldn't be practical for the engine to handle all=
 of
> > those cases.
>
> Can you put some detail in there ....I don't understand the problem,
> or what you mean by it not being practical to 'handle all of those
> cases' .

I can do that, I agree it probably isn't as clear as it could be.

One issue that was identified is that if this can be used anywhere a
string/constant can be used, there may be edge cases where there is no
way to handle an exception there because a try-catch isn't an
expression. For example, in attributes, I'm not 100% sure the engine
is set up to handle an exception being thrown while defining an
attribute, nor how you would catch such an exception in a graceful
way. I could be completely wrong, in which case I can add back that
option.

> > each one has its own merits but ultimately will
> > be left up as a secondary vote:
>
> One of the reasons the RFC process has served PHP pretty well is that
> it forces people to think through the details.
>
> I really don't think putting a few options up and hoping that people
> choose the best one is a good way to design a language; it allows
> skipping over thinking the details through.
>
> And yeah....this is one of the reason doing RFCs is annoying. People
> are often persnickety over details.

That is fair :)

After some discussions with colleagues, I realized how errors are
output and handled might be a contentious topic. I decided to make it
a secondary vote -- and hopefully -- the discussions we're having now
might inform voters on the best way to vote for how errors are
handled. I don't have a personal preference (but apparently some
people do), and I'd be happy with any of the solutions.