Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110666 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 72189 invoked from network); 18 Jun 2020 17:57:16 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 18 Jun 2020 17:57:16 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D9F3B18054D for ; Thu, 18 Jun 2020 09:43:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS8075 40.80.0.0/12 X-Spam-Virus: No X-Envelope-From: Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05olkn2016.outbound.protection.outlook.com [40.92.90.16]) (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 ; Thu, 18 Jun 2020 09:43:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EMNoGw2Ez5qWGCVuXQhID9E0WOaAWlePEkzKNyjkZ0p2Q1btoShfsuR6MjdY0eSaVwkGtIg68fphKfNz0s4NS199HQZZT9kYDKXf7sYjZbbppl+TWN1jIN+iSmk/JNwQlUZz4o6RKyKmLkH4tsfvGEG8LfZNrkvJOTD853Q3Nh5sT/WqBX2ABG9K7qmswO2fjHyZKlBVW2uDEhPfm+BOUw/09Qnvac+lXrJk7/JA5MKl+U92UruTBAMnr8tHULM7UNJQV1y1CLEBqJMhUJ1WI8/i+zb0nESERf57h3avZCjIB6nkAUu49yisD1HRpb6ae+zkezH7BGZbOXJCOitaFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uWhQtdRb0x7PZC8c4My3nad0kD6+vX1Y6jeN+kFuJj4=; b=RVPhIJviVDeGARaspnfgHh0SWYnxNz1Xg1Hb6irl9upeIxN3ZYfwBfg9cJnL8wsqeSefNSlyZ+a32SeTHTfMgG36RzeXqLeCvkTqqsYa3bg8Sn4V1YZ4xaVOPEVW5Ivn1ZoCaHIhLlthlRrPMFiGp4CKUCHZ2ZUXmwrjZllFY3xBYBSsr1iNr9OzC38448/QvP10QX4izESt+FWXQuta1W2S8sbWyscKrUdOFjlz6U2eWNY2jKqYwb6px5y2ygX4sFvgTnIfVgS9mDDhj/k1HPExrehynxVb0VUi0M0zk/2Mi11Tf8hPX7VAAkNwaz3/QeTZDNt4NgCNGq4GI5F1Wg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uWhQtdRb0x7PZC8c4My3nad0kD6+vX1Y6jeN+kFuJj4=; b=Fy9pvlhswd55DMb+tizF/xrWRBUM2g29X8VgkF9aig61A3jwO/+P6jw4IqDh00kpTzdCtcmS3ssVlZvBnPfc+7+NGb328XHT0+sGo96iu1xJvK5DrgV5BWW7Iovkq3HYz5XEMBpt0tQwOQeuGyAVfzatGG0Ckh6kc5gpqim0njzyIbVaU0t7mvIrk6PenxZytL54VMIdvnEwWWO5O2Zx6ubGRNNlcSpyfo7h0m6yzG0ri6hSOFDpFMf0jtoMB9Ku39gnik9Mho9gLHBvPBhi/bR9xYiI8qB7A0WEadc4FJRr32BsAxFluldheaF3nh3MnRFsdj3baWzWaBGVWAx8tw== Received: from AM6EUR05FT053.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc11::4b) by AM6EUR05HT142.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc11::483) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22; Thu, 18 Jun 2020 16:43:11 +0000 Received: from VI1PR02MB4703.eurprd02.prod.outlook.com (2a01:111:e400:fc11::40) by AM6EUR05FT053.mail.protection.outlook.com (2a01:111:e400:fc11::62) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Thu, 18 Jun 2020 16:43:11 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:8EC65077C8AF12CFEF231B2C738F7206E0DCFCEEBF45C2F7254C53332939615F;UpperCasedChecksum:CADDBF51986D115464E90BF35BE53F7E8B330CA129C2612167A35E1C12131F47;SizeAsReceived:9079;Count:48 Received: from VI1PR02MB4703.eurprd02.prod.outlook.com ([fe80::140a:b085:c1f0:e35]) by VI1PR02MB4703.eurprd02.prod.outlook.com ([fe80::140a:b085:c1f0:e35%4]) with mapi id 15.20.3088.029; Thu, 18 Jun 2020 16:43:11 +0000 Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_088DC175-FAA4-4C51-9099-F451F5078432" Date: Thu, 18 Jun 2020 18:43:08 +0200 In-Reply-To: Cc: PHP Internals List To: Benas IML References: X-Mailer: Apple Mail (2.3445.104.11) X-ClientProxiedBy: PR3P192CA0055.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:57::30) To VI1PR02MB4703.eurprd02.prod.outlook.com (2603:10a6:803:8f::13) X-Microsoft-Original-Message-ID: <10CD6799-ADA5-4D8C-BCF7-CE2288502253@hotmail.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPv6:2001:7e8:cb71:d400:acbd:faf1:907b:7654] (2001:7e8:cb71:d400:acbd:faf1:907b:7654) by PR3P192CA0055.EURP192.PROD.OUTLOOK.COM (2603:10a6:102:57::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.22 via Frontend Transport; Thu, 18 Jun 2020 16:43:10 +0000 X-Mailer: Apple Mail (2.3445.104.11) X-Microsoft-Original-Message-ID: <10CD6799-ADA5-4D8C-BCF7-CE2288502253@hotmail.com> X-TMN: [gndhn9yk/EPxWiabRzgbQ50/Glj+/3dsqmo+iz4sffkxoEjhvY8EJlIo3iJ6rM2B] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 48 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: b18c8dd8-4613-4c7a-bf59-08d813a6afa4 X-MS-TrafficTypeDiagnostic: AM6EUR05HT142: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bwaAEvmZAhTkIzK1vdQ5YYo6zI/NXhrQ4qq6C0SGxnMyoEilXPr9TVUR+RurBQ+1GJgoJfVA8yeDvaxsjSnnsQ6mmeBE/PR2KBqr4UwnNSWPMModBsseiTaZycdytw/IJkuon6UYbMpMzh4llYpt50GRJd3/yZMa9dLFni8XqjUHA+aMX/+JAyubuA39tspx6kWtA4bYIUt0r8QRbsZvjrKsexqgx+ZxAivu0bsCHxknX65yBClHwmagcR5WJzIN X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:0;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR02MB4703.eurprd02.prod.outlook.com;PTR:;CAT:NONE;SFTY:;SFS:;DIR:OUT;SFP:1901; X-MS-Exchange-AntiSpam-MessageData: Hs+Q63DNw95tEuwkuIpmKpe27WzQlP3mJLE1oRValNNJyTibaSV/aXhhBk7D5a/LOJtQFSgMHMFFu8VkwawmfHKrL8NHZm6yV36GQQ7OjcW576ZqShnWCODBrc0d4UsK9d2WxiyL1J3KoFGoAZFuBdQWEkHvlVfF/I+5Rjcuv4OVGhXY7LowA6n1BRamNtr2fcnT7HiufMEyArRmZL0R7A== X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: b18c8dd8-4613-4c7a-bf59-08d813a6afa4 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jun 2020 16:43:11.0400 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6EUR05HT142 Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void From: bobwei9@hotmail.com (Bob Weinand) --Apple-Mail=_088DC175-FAA4-4C51-9099-F451F5078432 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey, > Am 18.06.2020 um 17:18 schrieb Benas IML : >=20 > Hey Bob, >=20 > Magic methods are **never** supposed to be called directly (even more = if that method is a constructor or a destructor). If that's not the = case, it's just plain bad code. But by enforcing these rules, we make = sure that less of that (bad code) is written and as a result, we make = PHP code less bug-prone and easier to debug. That's also most likely the = reason why __construct() is invoked directly on parent calls, sometimes to = reinitialize an object or after = ReflectionClass::newInstanceWithoutConstructor. I invoke __destruct() directly when needing an early freeing of existing = resources. > "ensure magic methods' signature" RFC opted in to validate `__clone` = method's signature and ensure that it has `void` return type. >=20 > Just for the sake of making sure that you understand what I mean, here = are a couple of examples that show that no magic method is ever supposed = to be called directly: > ```php > // __toString > (string) $object; I like using ->__toString() in favor of (string) casts when the variable = is guaranteed to be an object to highlight that and avoid magic-ness. > // __invoke > $object(); Same here, unless the object is a closure. > // __serialize > serialize($object); > ``` Can't argue much about that one, I never use serialize(). > Moreover, by validating constructors/destructors and allowing an = explicit `void` return type declaration, we are becoming much more = consistent (something that PHP is striving for) with other magic methods = (e. g. `__clone`). Yeah, __clone() is odd. No idea why. > Also, saying that "sometimes you have valid information to pass from = the parent class" is quite an overstatement. After analyzing most of the = 95 Composer packages that had a potential BC break, I found out that = either they wanted to return early (that is still possible to do using = `return;`) or they added a `return something;` for no reason. Thus, no = libraries actually returned something useful and valid from a = constructor (as they shouldn't). >=20 > Last but certainly not least, constructors have one and only one = responsibility - to initialize an object. Whether you read Wikipedia's = or PHP manual's definition, a constructor does just that. It = initializes. So, the PHP manual is perfectly correct and documents the = correct return type that a constructor should have. It also is generally a bad idea to have side effects in constructors, = but _sometimes_ it is justified. Only because something mostly is a bad = idea, it is not always. Also note that other languages completely forbid manual ctor calls. But = PHP doesn't (and for good reason, like after using = ReflectionClass::newInstanceWithoutConstructor). Bob > Best regards, > Benas >=20 > On Thu, Jun 18, 2020, 4:06 PM Bob Weinand > wrote: > > Am 17.06.2020 um 01:10 schrieb Benas IML >: > >=20 > > Hey internals, > >=20 > > This is a completely refined, follow-up RFC to my original RFC. = Based on the > > feedback I have received, this PR implements full validation and = implicitly > > enforces `void` rules on constructors/destructors while also = allowing to > > declare an **optional** explicit `void` return type. Note, that = there is a > > small but justifiable BC break (as stated by the RFC). > >=20 > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void = > >=20 > > Best regards, > > Benas Seliuginas >=20 > Hey Benas, >=20 > I do not see any particular benefit from that RFC. >=20 > Regarding what the manual states - the manual is wrong there and thus = should be fixed in the manual. This is not an argument for changing = engine behaviour. >=20 > Sometimes a constructor (esp. of a parent class) or destructor may be = called manually. Sometimes you have valid information to pass from the = parent class. > With your RFC an arbitrary restriction is introduced necessitating an = extra method instead. >=20 > In general that RFC feels like "uh, __construct and __destruct are = mostly void, so let's enforce it =E2=80=A6 because we can"? >=20 > On these grounds and it being an additional (albeit mostly small) = unnecessary BC break, I'm not in favor of that RFC. >=20 > Bob --Apple-Mail=_088DC175-FAA4-4C51-9099-F451F5078432--