Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123994
Precedence: bulk
MIME-Version: 1.0
References: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com>
 <CANLbj-qvn-BFfN8hEQRciUuT_qCiiPfyqc=YiL1Pw5+Oy-Ad4Q@mail.gmail.com>
 <554ffb9e-35c5-466e-aace-0501eee3d0bd@bastelstu.be> <6452BECC-BB20-48DC-9595-324EA70E6A67@newclarity.net>
 <CANS-=pd2+aJbNiLBb9pS-m5JHATGOJKsAMN05nUDkbrPdDwYyQ@mail.gmail.com> <4148946E-7D16-46F8-8B88-9C7C5D61D129@koalephant.com>
In-Reply-To: <4148946E-7D16-46F8-8B88-9C7C5D61D129@koalephant.com>
Date: Fri, 28 Jun 2024 21:02:53 +0200
Message-ID: <CANS-=pcqq99B2LELKhJmAn+6deh=Su7X-YgLKwyqR=vvfZfhqw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Static class
To: Stephen Reay <php-lists@koalephant.com>
Cc: Mike Schinkel <mike@newclarity.net>, =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, 
	Bilge <bilge@scriptfusion.com>, php internals <internals@lists.php.net>, lnearwaju@gmail.com
Content-Type: multipart/alternative; boundary="000000000000a6cca1061bf7e610"
From: kjarli@gmail.com (Lynn)

--000000000000a6cca1061bf7e610
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 28, 2024 at 8:04=E2=80=AFPM Stephen Reay <php-lists@koalephant.=
com>
wrote:

>
>
> On 28 Jun 2024, at 14:05, Lynn <kjarli@gmail.com> wrote:
>
>
>
> On Fri, Jun 28, 2024 at 2:48=E2=80=AFAM Mike Schinkel <mike@newclarity.ne=
t> wrote:
>
>> >> and inheritance is not meant for code reuse.
>>
>> Just because code reuse in inheritance can be problematic it does not
>> have to be in all-cases. Moderation in all things. I used that approach =
for
>> 10+ years and never once had any of the problems people claim about usin=
g
>> inheritance for code reuse. This was likely because my needs were
>> constrained by the use-case and by nature did not grow out of control wi=
th
>> complexity.
>>
>
> My experience is the opposite. There are subtle bugs I keep running into
> with static function and properties causing unexpected behavior. I'm not
> against having static classes open by default for the sake of consistency=
,
> though my preference would be to avoid the headache altogether and just
> make them final by default so I won't ever have to deal with it. Would
> traits not solve the problem of horizontal reuse?
>
>
> Hi Lynn,
>
> I understand it's frustrating when there are bugs/unexpected behaviour,
> but wouldn't the (existing) *ability* to add the `final` keyword to a cla=
ss
> solve those issues for you, without preventing others from using the
> capabilities of parent/child class relationships?
>
>
> Cheers
>
>
> Stephen
>

The main issue is that it's easy to mess up by default and not messing up
requires you to understand why. I prefer defensive programming, close it
and only open when it's really required. If there's legit scenarios where
you need inheritance in a static context the requirement could be an "open"
keyword or removing it being final, we can't do it the other way around
without massive BC break.

--000000000000a6cca1061bf7e610
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 28, 2024 at 8:04=E2=80=AF=
PM Stephen Reay &lt;<a href=3D"mailto:php-lists@koalephant.com">php-lists@k=
oalephant.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div><br id=3D"m_-5573415878290394414lineBreakAtBeginningOfMes=
sage"><div><br><blockquote type=3D"cite"><div>On 28 Jun 2024, at 14:05, Lyn=
n &lt;<a href=3D"mailto:kjarli@gmail.com" target=3D"_blank">kjarli@gmail.co=
m</a>&gt; wrote:</div><br><div><div dir=3D"ltr"><div dir=3D"ltr"><br></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri=
, Jun 28, 2024 at 2:48=E2=80=AFAM Mike Schinkel &lt;<a href=3D"mailto:mike@=
newclarity.net" target=3D"_blank">mike@newclarity.net</a>&gt; wrote:</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">
&gt;&gt; and inheritance is not meant for code reuse.<br>
<br>
Just because code reuse in inheritance can be problematic it does not have =
to be in all-cases. Moderation in all things. I used that approach for 10+ =
years and never once had any of the problems people claim about using inher=
itance for code reuse. This was likely because my needs were constrained by=
 the use-case and by nature did not grow out of control with complexity.<br=
></blockquote><div><br></div><div>My experience is the opposite. There are =
subtle bugs I keep running into with static function and properties causing=
 unexpected behavior. I&#39;m not against having static classes open by def=
ault for the=C2=A0sake of consistency, though my preference would be to avo=
id the headache altogether and just make them final by default so I won&#39=
;t ever have to deal with it. Would traits not solve the=C2=A0problem of ho=
rizontal=C2=A0reuse?</div></div></div>
</div></blockquote></div><br><div>Hi Lynn,</div><div><br></div><div>I under=
stand it&#39;s frustrating when there are bugs/unexpected behaviour, but wo=
uldn&#39;t the (existing) *ability* to add the `final` keyword to a class s=
olve those issues for you, without preventing others from using the capabil=
ities of parent/child class relationships?</div><div><br></div><div><br></d=
iv><div>Cheers</div><div><br></div><div><br></div><div>Stephen=C2=A0</div><=
/div></blockquote><div><br></div><div>The main issue is that it&#39;s easy =
to mess up by default and not messing up requires you to understand why. I =
prefer defensive programming, close it and only open when it&#39;s really r=
equired. If there&#39;s legit scenarios where you need inheritance in a sta=
tic context the requirement could be an &quot;open&quot; keyword or removin=
g it being final, we can&#39;t do it the other way around without massive B=
C break.</div></div></div>

--000000000000a6cca1061bf7e610--