Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124284 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 829671A009C for ; Mon, 8 Jul 2024 10:10:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1720433499; bh=kroom/DBdpmV1dLk5xqegr6gQEJGeHfAPnY+3Fj574Q=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=W28J2Jzst0Ib0i/rYM47KxNJY3D6zvALWY7xoukvs/wBd6ESYUYfqZtaFPH97jr2R hA+dY05VDaI51PS0nAoYvs53LBhCb9TP2jUk32eVuLcyVgzGf41kCBUJRWjLJCNcPo c2XwiRqnXqdqwAVjUzWhb2X9anh0Qz2R7WSciyA2G9EEScCLhUahPiPJxUq813h73L v87iQlFgKdBTbCPJhcQew/LOUldXXRtTRAvSnEJB7IQoHb9KGd+XA+YJUSUuz31RAe KyBVULNoeM5qEg83TJoPZzbe7EnS6O0cam/d5xsQEHc2eTiglvI1vnGVEkRiAdsIbF BR9b+lXX6FiOA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D669D180929 for ; Mon, 8 Jul 2024 10:11:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,DMARC_MISSING, HTML_MESSAGE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail1.25mail.st (mail1.25mail.st [206.123.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 8 Jul 2024 10:11:38 +0000 (UTC) Received: from smtpclient.apple (unknown [49.48.221.3]) by mail1.25mail.st (Postfix) with ESMTPSA id 409AF603F3; Mon, 8 Jul 2024 10:10:04 +0000 (UTC) Message-ID: <3B6AF286-642C-4850-9577-B10049CE4C1E@koalephant.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4A380F6E-48E6-4D75-B9F5-5E9B8258E994" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: [PHP-DEV] [RFC] Static class Date: Mon, 8 Jul 2024 17:09:51 +0700 In-Reply-To: <743774dd-2281-458d-b0fa-d3e8806a3516@scriptfusion.com> Cc: Mike Schinkel , php internals To: Bilge References: <743774dd-2281-458d-b0fa-d3e8806a3516@scriptfusion.com> X-Mailer: Apple Mail (2.3774.600.62) From: php-lists@koalephant.com (Stephen Reay) --Apple-Mail=_4A380F6E-48E6-4D75-B9F5-5E9B8258E994 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 8 Jul 2024, at 14:42, Bilge wrote: >=20 > On 08/07/2024 01:16, Mike Schinkel wrote: >> Congrats on getting it to this point. > Thanks. It's been an adventure :^) >=20 >> I support this in all but the RFC's restriction on `abstract`, as I = have previously mentioned on the list. > I must have missed a key point here. Let's suppose we're writing a = follow-up RFC to permit `static` and `abstract` together. In as few = sentences as possible, what is the benefit conferred to the developer? >=20 > Cheers, > Bilge >=20 Hi, I'm sure Mike has his own answer for this, but I'm going to reiterate = mine again, because it apparently wasn't really understood the first = several times I said it: The reasons are two fold: (a) so that a static class can declare abstract methods either = explicitly or implicitly (by implementing an interface without providing = concrete implementations of all methods in the interface) (b) to keep consistency with regular classes.=20 The suggested static keyword for classes doesn't introduce any = additional behaviour that isn't already possible, it just prevents some = uses without the need for boilerplate - the main purpose is to "signify = developer intent". The actual behaviour applied to "static" classes is already possible in = PHP by simply omitting any instance members and declaring a private = constructor. These classes work fine with the abstract keyword. There = are no ambiguities, no gotchas or foot guns, there is nothing confusing. = It's a standard part of class hierarchy. So really the question should be: why do you feel the need to *disallow* = a combination that has no technical issues, and works already? If you're = going to disallow abstract why not disallow any class inheritance at = all? Because that's what abstract relates to: class hierarchy. Why = remove some support but keep the rest? Cheers Stephen=20 --Apple-Mail=_4A380F6E-48E6-4D75-B9F5-5E9B8258E994 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 8 Jul 2024, at 14:42, Bilge = <bilge@scriptfusion.com> wrote:

=20 =20
On 08/07/2024 01:16, Mike Schinkel wrote:
Congrats on getting it to this point.
Thanks. It's been an adventure :^)

I support this in all but the RFC's restriction on `abstract`, as I have previously mentioned on the list.

I must have missed a key point here. Let's suppose = we're writing a follow-up RFC to permit `static` and `abstract` together. In as few sentences as possible, what is the benefit conferred to the developer?

Cheers,
Bilge

=

Hi,

= I'm sure Mike has his own answer for this, but I'm going to reiterate = mine again, because it apparently wasn't really understood the first = several times I said it:

The reasons are two = fold:

(a) so that a static class can declare abstract = methods either explicitly or implicitly (by implementing an interface = without providing concrete implementations of all methods in the = interface)

(b) to keep consistency with regular = classes. 


The = suggested static keyword for classes doesn't introduce any additional = behaviour that isn't already possible, it just prevents some uses = without the need for boilerplate - the main purpose is to "signify = developer intent".

The actual = behaviour applied to "static" classes is already possible in PHP by = simply omitting any instance members and declaring a private = constructor. These classes work fine with the abstract keyword. There = are no ambiguities, no gotchas or foot guns, there is nothing confusing. = It's a standard part of class = hierarchy.


So really the = question should be: why do you feel the need to *disallow* a combination = that has no technical issues, and works already? If you're going to = disallow abstract why not disallow any class inheritance at all? Because = that's what abstract relates to: class hierarchy. Why remove some = support but keep the = rest?




Cheers

Stephen 

<= br>

= --Apple-Mail=_4A380F6E-48E6-4D75-B9F5-5E9B8258E994--