Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110623
MIME-Version: 1.0
References: <CABdc3WrM1bmef-GNZpoYgTj-RE4aCpC3SHsUP2=UgJ2zmDDOKw@mail.gmail.com>
 <37381398-3330-e5c3-4ae8-e668ca545194@lsces.uk>
In-Reply-To: <37381398-3330-e5c3-4ae8-e668ca545194@lsces.uk>
Date: Wed, 17 Jun 2020 11:46:12 +0200
Message-ID: <CABdc3WqbvNcc_j_+_wrYm6_SMawY+OFoDAxK-FQa+RvRwpyO8A@mail.gmail.com>
To: Lester Caine <lester@lsces.uk>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000006ee7d105a844880f"
Subject: Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Marcin_Brzuchalski?=)

--0000000000006ee7d105a844880f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Lester,

wt., 16 cze 2020 o 15:55 Lester Caine <lester@lsces.uk> napisa=C5=82(a):

> On 16/06/2020 13:14, Micha=C5=82 Brzuchalski wrote:
> > I'd like to start a discussion period for my RFC which proposes to chan=
ge
> > the use of "blacklist" in Opcache configuration with better
> > self-descriptive terminology.
>
> Since there will be a higher level change to all these terms - in all
> likelihood - trying to push yet another term that does not match the
> current discussions elsewhere seems somewhat premature. The NEXT RFC
> will be to bring this in line with the 'new' industrial standard, so is
> there any point jumping the gun before the international debate has
> finished? "blocklist", "banlist", and others all have appropriate
> application but like "excludelist", they all imply a narrower usage area
> while "blacklist" is accepted generally across all applications.
>
> What ever alternative to "blacklist" is adopted elsewhere is going to
> cause confusion and adding to that confusion with a different
> 'translation' just makes the situation worse?
>

Isn't that the more narrow term is used it's easier to understand?
We can easily vote on the right name.

I chose the "exclude list" cause the INI setting which changes name in this
proposal
is a glob path to filenames.
These files are then parsed as a list of glob paths for later file
exclusion on opcache run.
Another term in my mind is "ignore list" which then suggest a list of files
ignored by opcache run.

Regarding the "blocklist" I have to admit that it was my first thought but
after thinking IMO it's inappropriate.
There is nothing in the opcache what blocks files from being cached and
optimised,
they by themselves are not trying to be cached, cause the flow is from
opcache extension.

For me to whom English is not a native language first association is with
blocking service access to the clients
which interacts with the service and try to get access to it.
That's why I think it's inappropriate here and I've changed it in the
original patch.

The same goes for the "banlist" for me my first association is with the
client who had access to the service
but due to some policy reasons (like fo reg. destructive intentions or
overuse), the client lost access rights and
get's banned with assignnment to the "banlist".

Therefore IMO we should choose a new name wisely so it can be
self-descriptive.
What I can propose is update of RFC with a note regarding the second vote
for the right name.
I'd like to put there an "exclude_list" and "ignore_list", but if my
reasoning about not debating
on the "banlist" and/or "blocklist" is not enough then please let me know
then I can add those two also.

Cheers,
Micha=C5=82 Marcin Brzuchalski

--0000000000006ee7d105a844880f--