Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108290 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 94801 invoked from network); 28 Jan 2020 16:59:20 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Jan 2020 16:59:20 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 97F341804AC for ; Tue, 28 Jan 2020 07:09:44 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS8075 40.64.0.0/10 X-Spam-Virus: No X-Envelope-From: Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-oln040092003073.outbound.protection.outlook.com [40.92.3.73]) (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 ; Tue, 28 Jan 2020 07:09:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VWF9aD2XIMdCINyEJ9DoKEKSxocs0GyYOMQMQLGSIhoY2WrMN+2CmjGXxjYmmZHYZoa5icqam1x37wtKCrV7O4DHar+CivwO56Fy0KfaZgyWboVnhnxwm0ovN/cxPdZnzaV6h8iXiw73FeT2lQXeHGqGKpBzLkHYqzYlsU2R4TmmsTKlrthWPJSEVRPAAKCWltJBOh76vHSCNTUGXTTRB7UXgcCOguXaQDe2tI4zPa+v1QdiGG/qdNjWFcuXYvJXKRhRrQ6KqUcRe4w81Tz7e1boGTd4I+Bhk415w9EVKQtqzTdPywzK96Qq+AAIzHf+HmsqAG1NDhcg8I1N+/xCaA== 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=h9xwjiGIrtFW+teE/sb5ykSdtCp8mbOd/2qOPenGdoA=; b=e8uIFcnmUDTkftSW1QdSNC5K+bMAjEhdbpHSUwOKUsCgVyI2+Gz9GbC4ca+F+tv526I1JEyZDKeT9FrbvLBhbsjjuEhNjKeUEbJHBAykipdud5P1xeXYhQoaKITShoMWOj2lCYKhMOh4j+zWZiwSP9I+p+8pgBbyDRZrV/IDa/j20f0OaM5j9skQGT7ecOYI1NW8ufVmcG3VCwjAu6IaETDIvKMXOJFO5vyNo4LaSGba2Yw5tpQLH/TnXehQhK5PAbXLobL+zk+9ZLtgpJMbcykwboaDgzLQfOP2xL6bQSocXb6sBVzn/LT3thnlsODJdvJj8sfJhlru9akbHMCetw== 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=h9xwjiGIrtFW+teE/sb5ykSdtCp8mbOd/2qOPenGdoA=; b=q/x3LyfgF7tymlcLqbxMw9f1zeSDtX25HwrUOBra6hMJWTSCLrBFpHrBF2RFaIxflsfmo8wRqF1Ve9XJm3kLIzjtS3lKpekm+g49zQgq9akGsumswjNXNOOeUNqkW7Af98eavJOyoNpJdnGUNOVPqKyaS1//SkT9Phr+O/noKIDxKIPYdlHNMMcQmhlMM6dXmL0+k+VZIcDWGcU9gfjX9cC0fp+y7OdCTt0jNDf3Y0fMmLVZGUJXHSkYcnD0zu52C5tHWk47vOXmKsd5oNuEAi5zvV4fWUK8hod3SyidYDzujqAfDjipEztf/iGQgfgii1XOlGsR9cg8lAj7wccVmw== Received: from CY1NAM02FT032.eop-nam02.prod.protection.outlook.com (10.152.74.57) by CY1NAM02HT165.eop-nam02.prod.protection.outlook.com (10.152.75.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.18; Tue, 28 Jan 2020 15:09:42 +0000 Received: from DM5PR07MB3067.namprd07.prod.outlook.com (10.152.74.55) by CY1NAM02FT032.mail.protection.outlook.com (10.152.75.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.18 via Frontend Transport; Tue, 28 Jan 2020 15:09:42 +0000 Received: from DM5PR07MB3067.namprd07.prod.outlook.com ([fe80::29e3:53bf:163e:5beb]) by DM5PR07MB3067.namprd07.prod.outlook.com ([fe80::29e3:53bf:163e:5beb%3]) with mapi id 15.20.2665.026; Tue, 28 Jan 2020 15:09:42 +0000 To: Nicolas Grekas CC: "internals@lists.php.net" Thread-Topic: [PHP-DEV] Re: [RFC] "use global functions/consts" statement Thread-Index: AQHVwNgGtev425C1jEaW2/fYCDQJoKfqjUCogAA6vwCAABZSCIAF7qHQgAA+1YCAABKbIoAI/p4AgAAC2gCABEpcgIAAVS8WgAE/ygCAAFgwcA== Date: Tue, 28 Jan 2020 15:09:41 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:D2F7F79AF78E6B91EC8ED30E9961B80F65D9EE9C644C0263F16F960B46CBEB31;UpperCasedChecksum:7AD1096738A818609A079A9F57685BBD2F6F605635D06671BE9F97F00EDD8B39;SizeAsReceived:7984;Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [mnw6qt21eMu15oVBQDXjnA+T2Xv1xK6n] x-ms-publictraffictype: Email x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: da61e545-8a27-479b-ee3c-08d7a4041a1b x-ms-traffictypediagnostic: CY1NAM02HT165: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /D6mwKvqa3hBrbEzhwfr1I2A8pVd4nsCRN5UmzyDOQ/W3ihGYZmHyrYhBMWdWprL6dOMh3AvzV/3XCLUUqoXVYBUnZxWmd639ST+4uhKd1plAVEgAg0i4cZBKp7n2AN5F4BQAtARsnX78V0xvsdkDpdHsH7XmxjkrTh9Kig8SH1r0hvj/oIrfBY03nDM5cCQTILwSaLhYhTiC34x9asjXwzwMFj9AaTivL/rsy/E70c= x-ms-exchange-antispam-messagedata: c2R+c5zjVnxm9hwo93uKfh3JmgnVcxcp/7D7ZkxTHHmwDNQ0Ze8zUV5X9AQrrhVNACBjve0r9VbwWVvLFAwy7qVGZVnEN94uA0/t5DdQwVZwzhCRxbSgmZ6l/7H/Z+ptBhTAbwwoY5nkELY7NjJ5HQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: da61e545-8a27-479b-ee3c-08d7a4041a1b X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2020 15:09:41.9607 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT165 Subject: Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement From: tysonandre775@hotmail.com (tyson andre) > Thanks. It's a bit strange to read the objections to the proposal in the = RFC.=0A= > That makes it feel like "we" agreed on them - while it's "only" the autho= r's opinion. From this part in the RFC:=0A= =0A= It's included because https://wiki.php.net/rfc/howto mentions the following= :=0A= =0A= "Listen to the feedback, and try to answer/resolve all questions.=0A= Update your RFC to document all the issues and discussions.=0A= *Cover both the positive and negative arguments.* Put the RFC URL into all = your replies."=0A= =0A= This is why I included major points from the arguments for/against=0A= in https://wiki.php.net/rfc/use_global_elements=0A= =0A= > > and changing that default would require changing a lot of third party c= ode.=0A= >=0A= > not unless it's opt-in, which it is.=0A= =0A= Good point, I've changed this to be clearer about what I meant and add miss= ing details..=0A= =0A= > It's fairly common for NS\SubNS\ClassName to mention other classes from N= S\SubNS\OtherClassName right now,=0A= > (more commonly than use Exception, use Throwable, etc in some cases),=0A= > and [opting into that a single setting such as declare(global_lookup=3D1)= ]=0A= > would require changing a lot of third party code [to get unambiguous func= tion and constant resolution easily].=0A= > A separate option such as `declare(lookup_classes=3Dglobal)` would allow = migrating to that,=0A= > but would confuse developers switching between codebases using different = settings of lookup_classes,=0A= > and introduce similar confusion about the rare case of multiple classes i= n one file.=0A= =0A= > > A separate option such as `declare(lookup_classes=3Dglobal)` would allo= w migrating to that,=0A= >=0A= > better have lesser declare() directives IMHO.=0A= =0A= It's impossible to agree on everything. I don't believe anyone's actively w= orking on `lookup_classes` or `global_lookup` right now,=0A= so there might still be only one declare directive for name lookup a long t= ime from now.=0A= =0A= > but would confuse developers switching between codebases using different = settings of lookup_classes,=0A= > and introduce similar confusion about the rare case of multiple classes i= n one file.=0A= =0A= Not sure how this would be different than any other declare directive - eit= her the currently proposed one or even strict_mode.=0A= =0A= =0A= https://wiki.php.net/rfc/use_global_elements is opt-in, and also doesn't ne= ed to deprecate anything. The link you mention=0A= is a different proposal that has deprecations for constants and functions.= =0A= =0A= > > > I'm not comfortable with having a 3-ways declare directive. Who will = pick which of the 3 and for what reason?=0A= > > > That's going to be a mess to review. If we're looking for a forward p= ath, there should be only one opt-in way: a boolean flag.=0A= >=0A= > > I'm not sure what you mean by 3 ways. It's at most two, and a setting f= or global name lookup might become mutually exclusive (forbid using both se= tting names)=0A= >=0A= > I meant 'default', 'fallback', 'global', and declare()-omitted. Rowan's l= atest message is a better ground to discuss this so let's continue there - = I share his concerns.=0A= =0A= For the reasons I mentioned earlier, I don't want to add a 'fallback' setti= ng 2 ways either,=0A= because it'd potentially constrain other RFCs unrelated to this one in ways= I can't anticipate.=0A= (e.g. will they emit a deprecation notice for 'fallback' and suggest using = 'fallback_v2' or a new 'default'?)=0A= =0A= > > You mention this should be another RFC. But process-wise, I think it wo= uld be better to vote only once on a specific topic, vs having several iter= ations that undo previous RFCs before having a stable consensus.=0A= >=0A= > The issue with that is that there's no good way to set up a vote or poll = for that in the RFC structure.=0A= >=0A= > For sure, I'm not suggesting to add a sub-vote. I think we should be able= to discuss the best proposal we can imagine all together and put it under = a yes/no vote.=0A= =0A= - There were a lot of edge cases to work out for functions and constants, a= nd many approaches to dealing with that.=0A= =0A= There would similarly be edge cases for classes, and the same approach of= adding `use MyNS\MyName;`=0A= before the class declaration `class MyName` would have other objections,= =0A= and would probably also affect the resolution of=0A= namespaces (`MyName\MySubNS\MyActualClass` and `MyName\my_function()`=0A= - Implementing and discussing changes to class resolution to see if they wo= uld be viable or has unexpected edge cases (while creating a proposal befor= e voting on it) is time intensive.=0A= =0A= If I expect a vote on additionally changing class resolution to fail due = to the edge cases and drawbacks I mentioned=0A= or objections to the final proposal, there's less incentive to personally= do that work,=0A= and I'm not aware of other developers working on a detailed proposal for = changing class resolution.=0A= =0A= The alternative of not creating an implementation it and not creating a d= raft RFC before voting would lead people to vote on something with an incom= plete understanding=0A= of the impacts and viability of changing class (and possibly namespace) r= esolution.=0A= =0A= Of course, I could be completely misjudging interest,=0A= and an RFC for opt-in changes to class resolution may pass and solve these = issues in ways I couldn't think of right now.=0A= =0A= > > I'd see global_lookup=3D1 and function_and_const_lookup=3D'global' as b= eing significantly different in who would vote on them.=0A= > > The former requires a lot more refactoring and code changes to handle c= hanges to class name resolution,=0A= > > compared to the code changes of just changing function and constant res= olution.=0A= >=0A= > No proposal requires any refactoring if things are opt-in: existing codeb= ases will continue to work as-is.=0A= > New ones might start with the new declare directive. Existing codebases c= ould also adopt the directive once the tooling is ready. Eg. php-cs-fixer h= as all the required infrastructure to automate this transition *for authors= that want to do it*.=0A= =0A= =0A= =0A= > And because changing resolution of class names has those drawbacks, I don= 't plan to change direction within this RFC.=0A= >=0A= > I don't see these as drawbacks, especially when the target is cleaning up= the rules of the engine for a better future :)=0A= >=0A= > Can you please consider it? While this reply might feel like I'm "just" c= riticizing your work, it's not: I'm very thankful for what you're doing her= e and I think you are doing a great job.=0A= > I'm "just" trying to help shape the best proposal for the best future of = PHP, although very modestly :)=0A= =0A= I am thankful for all of the feedback on the RFC.=0A= I have considered the feedback and responded to it,=0A= but I just see too many potential problems with changing class resolution= =0A= to be included in the scope of this RFC.=0A=