Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105209 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 6639 invoked from network); 10 Apr 2019 17:51:29 -0000 Received: from unknown (HELO NAM02-SN1-obe.outbound.protection.outlook.com) (40.92.5.96) by pb1.pair.com with SMTP; 10 Apr 2019 17:51:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oHO5/tBWXAp/YV0KvHRPSqEiOFtQDSVN/GpLcZgbw6w=; b=naNsjVy03ylMyELyyIC75604F7wKEk2NhmaZfwgPk5qIuSyqQb3yif+BGuxADiZ71kkrawjBYcD0+0SN5UotDEjSrD4lyJ+B6UUFkZolJzBwsxPZeR4VYx+YoCNDHuhl+nQZTGA6pDhZFmqv5pqt2Lh5Gszjv+CjFzBj964r2HnJUHNhimJpVMKG0/rfDiKXee0wr5aMvZ8F5NLN3N/ACKl+3g8Crdr+z9w4quvK3tVF0c5XUuBiA5PiGg1zMJXlBVh4U5Vg7NQWEZ/guigntvlqerVrTx/KIG79cCyPuYvtc0U8LtlCqgPNsdTJws2cmmaxaoccBGr3Cj0PLqrvLQ== Received: from CY1NAM02FT009.eop-nam02.prod.protection.outlook.com (10.152.74.53) by CY1NAM02HT024.eop-nam02.prod.protection.outlook.com (10.152.75.0) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1771.16; Wed, 10 Apr 2019 14:48:37 +0000 Received: from DM5PR06MB2857.namprd06.prod.outlook.com (10.152.74.59) by CY1NAM02FT009.mail.protection.outlook.com (10.152.75.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1771.16 via Frontend Transport; Wed, 10 Apr 2019 14:48:37 +0000 Received: from DM5PR06MB2857.namprd06.prod.outlook.com ([fe80::447:30c5:3c4c:5294]) by DM5PR06MB2857.namprd06.prod.outlook.com ([fe80::447:30c5:3c4c:5294%8]) with mapi id 15.20.1771.016; Wed, 10 Apr 2019 14:48:37 +0000 To: Gabriel O , Levi Morrison CC: Dan Ackroyd , PHP internals Thread-Topic: [PHP-DEV] [RFC] Always generate fatal error for incompatible method signatures Thread-Index: AQHU7q3ZkDUlFRPPOUWDfKA/8jHC06YzqPQAgABACYCAAAOHgIAACdIAgAAIcACAAXwuvA== Date: Wed, 10 Apr 2019 14:48:37 +0000 Message-ID: References: <3BCEA463-BD9B-468B-AF26-E0AD75C5F559@gmail.com> <16a029d2430.27c1.08be835b7d1a2c2edb4c4286afe1a236@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:29DE321AC98441A762C48DFC5F96639DE6EE14841F62D5617374E276DA71309B;UpperCasedChecksum:C432F216F18DFD3E1DC5BB434C66071F68FA7FBEB569B4D16FA3F7B8165939BA;SizeAsReceived:7324;Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [NtnUk4EPHJYXOvYm9pvuYolJy48Hh+no] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031323274)(2017031324274)(2017031322404)(1601125500)(1603101475)(1701031045);SRVR:CY1NAM02HT024; x-ms-traffictypediagnostic: CY1NAM02HT024: x-microsoft-antispam-message-info: 7dW1YM/qCR412GR949x6p6H526F09jVRMGR2tVjQh6BMHYK2Hj+/XGueHBwSFn03mDP3wF5mc+w5+eSPrgIdtfFpMAeNTc/JGviGVDn7Un4zdS0zsUiAwASH3rBS9doAfKh53jEEqqwhhCUA/908ptA+ovxKNl+d/n2ajzwYOEPiH5lcQ+SdhSQQtLfaneZx Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 20312a8b-a613-4f3b-4efe-08d6bdc39d41 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 14:48:37.3198 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT024 Subject: Re: [PHP-DEV] [RFC] Always generate fatal error for incompatible method signatures From: theodorejb@outlook.com (Theodore Brown) On Tue, Apr 9, 2019 at 11:05 AM Gabriel O wrote:=0A= =0A= >> On 9. Apr 2019, at 17:35, Levi Morrison wrote:=0A= >>=0A= >> If you want the reverse to be true, then your code has bugs waiting to= =0A= >> show themselves. The earlier we can catch these bugs, the better.=0A= >>=0A= >> One thing to note is that return type information does permit=0A= >> optimizations in some cases. For instance, I believe if a private=0A= >> method has a return type constraint of int, then the optimizer can=0A= >> rule out certain edge cases, and in some cases use type specialized=0A= >> handlers. We can do these sorts of optimizations in more places if the= =0A= >> LSP issues are always errors, instead of warnings.=0A= >>=0A= >> So for both correctness and performance, I support this change.=0A= >=0A= >=0A= >> If you want the reverse to be true, then your code has bugs waiting to= =0A= >> show themselves=0A= >=0A= > I don=92t, I just don=92t want fatal errors in production when I upgrade= =0A= > library I extend. Let me keep logging such issues and fix them later,=0A= > instead of producing hard crash for customers.=0A= >=0A= >> The earlier we can catch these bugs, the better.=0A= >=0A= > What prevents somebody to catch warnings? This RFC is about hard crash=0A= > that I disagree with. This type of issue is problematic only when=0A= > expecting parent but injecting child.=0A= =0A= Have you considered testing your code in a dev environment after=0A= upgrading a library you extend, prior to pushing it to production?=0A= If you blindly push library updates to production without testing,=0A= there are many other types of errors you could run into besides this.=0A= =0A= I for one would welcome consistent fatal errors for LSP violations,=0A= to catch these kind of bugs as early as possible during development.=0A=