Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126782
Precedence: bulk
MIME-Version: 1.0
References: <084101db94b8$73da47e0$5b8ed7a0$@glaive.pro> <c6d0feddba246329ff5841c967a9206e@glaive.pro>
In-Reply-To: <c6d0feddba246329ff5841c967a9206e@glaive.pro>
Date: Sun, 16 Mar 2025 09:18:50 +0200
Message-ID: <CAAwdEzCcQ6OKdEyK8evXL75-eRCsm575u7-iQ-PAz9MqOWUdPA@mail.gmail.com>
Subject: Re: [PHP-DEV] [VOTE] Optional Interfaces
To: Juris Evertovskis <juris@glaive.pro>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000079cb050630707c33"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--00000000000079cb050630707c33
Content-Type: text/plain; charset="UTF-8"

On Sat, Mar 15, 2025, 11:25 Juris Evertovskis <juris@glaive.pro> wrote:

> The key point, hoewever, seems to be that the naming of the feature is
> excremental and very easy to misunderstand. I suppose the naming issue can
> be solved separately (if a better name is found) and the documentation can
> use a different naming and description if the RFC itself passes.
>
>
>
Hi Juris,

Looking a bit into the naming issue, it feels like shifting from "optional
interface" to "optionally implements interfaces" is something that could
have help.
The RFC could have used throughout the text the adverb "optionally" to the
verb "to implement" or adjective "optional" to "implementation" instead of
as an adjective to "interface".
Also the name would have been "optional interface implementation".

If you agree, and if the RFC passes, this could at least be documented as
such.

Was not able to find other words that matches better, as all have some
drawbacks.

-- 
Alex

--00000000000079cb050630707c33
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><br><br><div class=3D"gmail_quote" dir=3D"auto"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sat, Mar 15, 2025, 11:25 Juris Evertovskis=
 &lt;<a href=3D"mailto:juris@glaive.pro" rel=3D"noreferrer noreferrer" targ=
et=3D"_blank">juris@glaive.pro</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div style=3D"font-size:10pt;font-family:Verdana,Geneva,sans-ser=
if">
<p id=3D"m_-1512873537326809921m_-5961118405928066356m_5536145259576508114r=
eply-intro"><span style=3D"font-size:10pt">The key point, hoewever, seems t=
o be that the naming of the feature is excremental and very easy to misunde=
rstand. I suppose the naming issue can be solved separately (if a better na=
me is found) and the documentation can use a different naming and descripti=
on if the RFC itself passes.</span></p>
<p><br></p></div></blockquote></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">Hi Juris,</div><div dir=3D"auto"><br></div><div dir=3D"auto">Looking=
 a bit into the naming issue, it feels like shifting from &quot;optional in=
terface&quot; to &quot;optionally implements interfaces&quot; is something =
that could have help.</div><div dir=3D"auto">The RFC could have used throug=
hout the text the adverb &quot;optionally&quot; to the verb &quot;to implem=
ent&quot; or adjective &quot;optional&quot; to &quot;implementation&quot; i=
nstead of as an adjective to &quot;interface&quot;.=C2=A0</div><div dir=3D"=
auto">Also the name would have been &quot;optional interface implementation=
&quot;.</div><div dir=3D"auto"><br></div><div dir=3D"auto">If you agree, an=
d if the RFC passes, this could at least be documented as such.</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Was not able to find other words th=
at matches better, as all have some drawbacks.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">--=C2=A0</div><div dir=3D"auto">Alex</div><div dir=
=3D"auto"><br></div></div>

--00000000000079cb050630707c33--