Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126562
To: "'php internals'" <internals@lists.php.net>
References: <087a01db596a$e7525660$b5f70320$@glaive.pro> <045501db7b37$e1f15970$a5d40c50$@glaive.pro>
In-Reply-To: <045501db7b37$e1f15970$a5d40c50$@glaive.pro>
Subject: RE: [PHP-DEV] [RFC] [Discussion] Optional interfaces
Date: Tue, 4 Mar 2025 22:59:48 +0200
Message-ID: <038601db8d48$5dfb65c0$19f23140$@glaive.pro>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0387_01DB8D59.2184AAF0"
Thread-Index: AQF7k6cGPGLx4SotLMUdlMWx2/alYAJeABjStBBubIA=
Content-Language: lv
From: juris@glaive.pro ("Juris Evertovskis")

This is a multipart message in MIME format.

------=_NextPart_000_0387_01DB8D59.2184AAF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi all,

 

It's almost awkward to bother the list with this humble RFC amidst so many
exciting proposals :)

 

With help from Ilija and Niels the implementation is now working and tested,
so the RFC seems getting closer to the voting phase.

 

Ilija raised a point about optional interfaces not being a reliable
"overridable" for `#[Override]`. I can certainly understand that concern.

 

At the same time I think there could be value in being able to say "although
all overridables are optional, this method must override something, so at
least one of them must be present". This would be applicable when a package
provides compatibility with multiple tools (or versions of a tool), but
still requires at least one of them to be present. Besides I think that
using `#[Override]` with an optional interface would be a very deliberate
step so such consequences would be not only expected, but intended.

 

I've added an example illustrating this to the RFC. Does this justification
make sense or does it sound like a horrible design? Would it be better
suited for a secondary vote? I haven't yet investigated how complex it would
be to let Overrides ignore optional interfaces as non-existant.

 

Does anyone have strong feelings on this or any other concerns?

 

BR,

Juris


------=_NextPart_000_0387_01DB8D59.2184AAF0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 15 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	font-size:11.0pt;
	font-family:"Aptos",sans-serif;
	mso-ligatures:standardcontextual;
	mso-fareast-language:EN-US;}
span.EpastaStils19
	{mso-style-type:personal-reply;
	font-family:"Aptos",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;
	mso-ligatures:none;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DLV =
link=3D"#467886" vlink=3D"#96607D" style=3D'word-wrap:break-word'><div =
class=3DWordSection1><p class=3DMsoNormal>Hi all,<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>It&#8217;s =
almost awkward to bother the list with this humble RFC amidst so many =
exciting proposals :)<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>With help =
from Ilija and Niels the implementation is now working and tested, so =
the RFC seems getting closer to the voting phase.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>Ilija raised =
a point about optional interfaces not being a reliable =
&#8220;overridable&#8221; for `#[Override]`. I can certainly understand =
that concern.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>At the same time I think there could be value in being =
able to say &#8220;although all overridables are optional, this method =
must override something, so at least one of them must be present&#8221;. =
This would be applicable when a package provides compatibility with =
multiple tools (or versions of a tool), but still requires at least one =
of them to be present. Besides I think that using `#[Override]` with an =
optional interface would be a very deliberate step so such consequences =
would be not only expected, but intended.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>I&#8217;ve =
added an example illustrating this to the RFC. Does this justification =
make sense or does it sound like a horrible design? Would it be better =
suited for a secondary vote? I haven&#8217;t yet investigated how =
complex it would be to let Overrides ignore optional interfaces as =
non-existant.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>Does anyone have strong feelings on this or any other =
concerns?<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>BR,<o:p></o:p></p><p =
class=3DMsoNormal>Juris<o:p></o:p></p></div></body></html>
------=_NextPart_000_0387_01DB8D59.2184AAF0--