Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108275 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 94529 invoked from network); 27 Jan 2020 20:26:08 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 27 Jan 2020 20:26:08 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 41372180545 for ; Mon, 27 Jan 2020 10:36:21 -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 NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12olkn2099.outbound.protection.outlook.com [40.92.22.99]) (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, 27 Jan 2020 10:36:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G75+QfBfKk/udgxsRDRKAdLf+iUYthjUFS7CYI68s2ULTiSEnS3dir6RcccWnoVCgEqXLFfQM8rodMX3ZtKFfV83+lOknfkDJpQzOEWbl4ZIH1SpAObRtUJAuyYGS4oV14iaQO1if3MZWUGuFVdPKThqK5aRyXcTMBTSK3feH7kakha5ux6Tv4oIR20kpDQq+CVMylbhufYgsJ/2NUmrM3bZMA6NpoZ7/I9PMtptLV2OXukwVT0HNKHPLGyq1j2OHBeitRkA6XQlNZPjbymG8/xUEYP2dyey+9Nozlj7p6+UZ0TdKVyWl7cmEJWxwKmyl+8YHZ0Li6w4Ds/NZH1PKQ== 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=3iiBeYJ7e8cdfGybGnEV74l2U0WJeqkcymDasU+f3hA=; b=CLX9SzpDhEsCZkBOMWqXHnkB9gK8xxUuLHwLHPQaqvxezYfPJ8o7K+Oa3qzKpknwDqChMisNBc36F7Yxzvx17UFF7jW/BqAnYFokgzpc6a5dom/WcZnTL7hh94l2436jg+rnWU+N/IcOSiw+G6BbTOuA+06JjpaV9ALqjwJuMLT34HSr/L2pM6qiG7y9PMXtys75HQ97tGJT7dlLowudEjnsIlFcZ26G6JCz6a/7z70gMdfRN7tN1iuSui1FCVnegUJD+gML79ZBwmXML/O42lkVKAI3Ea6iCJN5jRTgK4Lza8NxErNuH+TN30UWRq4ai4g7opB9wnAYhXeDaXHtPw== 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=3iiBeYJ7e8cdfGybGnEV74l2U0WJeqkcymDasU+f3hA=; b=C5COMKiWA1JFINUIHMrtn4q045RsBvGdHbOCUIDA6BW425YJtfKgzU7jmmLM0KWtZut2PviiMYjc5Pgf3Nf2+WHtgw9pEgVosB+kHHNS0QY+hymdVxEvFg4rUFYi0WEF93d3ltNp7qW4OnbU1JP9IDdfwIEoxXaUaeYKbA7L6iacNsVzQpGWgOseuEVFnVSjODvDa/LHz8vposGTADgwpbXcfPOoNQAvnTez5DW3Cum0G+gIDDYrDW/2N3RNMgNZYmojOJNLO7t3tnxFKGu9Tl1ZVoJTOkejgj3J2gJ+OWkwpJ0IZgNDD67wSC8zXimZnbggYDqiMD3GPUaNY0smKQ== Received: from MW2NAM12FT008.eop-nam12.prod.protection.outlook.com (10.13.180.55) by MW2NAM12HT131.eop-nam12.prod.protection.outlook.com (10.13.181.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.12; Mon, 27 Jan 2020 18:36:18 +0000 Received: from DM5PR07MB3067.namprd07.prod.outlook.com (10.13.180.53) by MW2NAM12FT008.mail.protection.outlook.com (10.13.180.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.12 via Frontend Transport; Mon, 27 Jan 2020 18:36:18 +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; Mon, 27 Jan 2020 18:36:18 +0000 To: Theodore Brown , Nikita Popov CC: Nicolas Grekas , Mark Randall , "internals@lists.php.net" Thread-Topic: [PHP-DEV] Re: [RFC] "use global functions/consts" statement Thread-Index: AQHVwNgGtev425C1jEaW2/fYCDQJoKfqjUCogAA6vwCAABZSCIAF7qHQgAA+1YCAABKbIoAI/p4AgAAC2gCAABgFtYACp60AgABaA0aAAIW5VoABP9mJ Date: Mon, 27 Jan 2020 18:36:18 +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:C7B9390DE1DF86E74C0134FB2D3492883F427FEE1C3995B194894B134EBE4DE5;UpperCasedChecksum:618EC0CF2A9A1152AA8A14B77A1B353876F68ACD7603EE7E4D3DA50F7423B78D;SizeAsReceived:8192;Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [JeS5nKXhM6QtXYqV/vOdPUotJZoLezgK] x-ms-publictraffictype: Email x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 7c17ad1c-8bb4-46d5-75bf-08d7a357cc92 x-ms-exchange-slblob-mailprops: =?iso-8859-1?Q?2wZiaeRZSayUbGNJN0BgdAA2YoB+RuQVkHlj9kc3vB4v4OWYBdMBGvBmcL?= =?iso-8859-1?Q?9YnVPyHNH0mnAgtYZdG30mHgEvFwbImZcUKduYIiovEvPOILSlRWjDgbTe?= =?iso-8859-1?Q?BC9R8sUiC6frcbMmQKPtacX5DwT2P9lGUqJQNeAbiM23pELqWfrvKKlNKN?= =?iso-8859-1?Q?vYrpQtlcwe93CwT0mcVEzQIn2RIqkXnyiZmoIs4/sr0M0k4ZxSf9uF2qvx?= =?iso-8859-1?Q?HtDgZTeUsUcOSgeAVheD3YRNFaDW+itB5PkAdUVvNJ16Fn2I1zQMUp9yXc?= =?iso-8859-1?Q?pcmXYYPbVe1GSDDUTWDWgksmgWDelMJ/BFRBiabgbMeHKdcxxAe4Wqt8UN?= =?iso-8859-1?Q?0zKe3GO6fFtamq9nHnrAU6VxS+N21o+DHqH6CFDs7KVB5WrT4inBbOIeqR?= =?iso-8859-1?Q?MW6IX5R3660TmfJwnVrhMdTUFzhTzMa4TJHCM9RPo0y0KwNpEA4UWbhP2e?= =?iso-8859-1?Q?QiA3RwUP7gTdrCWvx0D/O3Zc4aMJCJYjgekbzS8S7GV26H7ld139baXhpn?= =?iso-8859-1?Q?pJ3/CRGbHIMpzyOZgK2vQL6xk9Wnx6l7DYi3dQvPSJp+pKeOVFDWeUgCXW?= =?iso-8859-1?Q?o4PeM50jc7Potjop+RP547JegHeLGgqhjB+aT6hVi+Tu5bdhAxTIOhnlpg?= =?iso-8859-1?Q?UPkxj1XxNNRPt+FWJ/BsWwOxf7h26sEnJVJXkgLiZ7AXAAEcyv8oWfj7JD?= =?iso-8859-1?Q?QBp/Im88t4Y3dp6p6per0t5Tp/KWu8OSHSal3uBgdsoTMUbMj3v1Ewpdmt?= =?iso-8859-1?Q?yqBwlkEfbWB955J4NN1xKNuq1mqbpnCCPRYKKuo2E8d7dHi9FoIqIG3ajA?= =?iso-8859-1?Q?BPTtB4pkmF2jBu0Wm/z5htqFkTGGgp+MXxKS2OBYrY1qdFwIlsh6Sipxj5?= =?iso-8859-1?Q?RAxxamM/7i3ERKIs8ajbSz4B5u3Nx+GyD/LbRaHm85Rp0ghDE8jgbapnhB?= =?iso-8859-1?Q?8WyX73Hkry7RFiVs/nuZ7rZstrjlspPC+4v/oB3bKBxkayw/rqnioIilR7?= =?iso-8859-1?Q?Mv1S5gVnGUjkpeQkvM1O8qgSHl2pG0+ku0OUgSB0lKAalpPdhLtl+NkWiR?= =?iso-8859-1?Q?opkC7iSDpaxR8VL7YvrWmXy6TRuXtb9FvXULT8lSQrWfbsQEVEuguRo=3D?= x-ms-traffictypediagnostic: MW2NAM12HT131: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CRqTqmhMBraHBy5KRDR/5Ry2T+iU1WHQJQpLU2uM3tItjLaaP4+7GOvG0e+/Pl3eC5uTa8c0qocUWzMG84ch4D0mPXQsZ8xqv5k95/KgaP5maHLtIK78qi2+yqKWiVxatXfYcESB6FTS5moyaC6Jv7ykOlQL9sTaxU7qDlI2F9egiagdEtJEI5PcfBtgzY7+NjwJLCCKEFtKoiFZ+uWT31o2c7Z1Ans1Sl9jz2cv6PY= x-ms-exchange-antispam-messagedata: jWxORakrHKPDcx+rbFCkrjOBH4K3yfX51PCmF71F/7AXY3c6nS+0TH4nzRgNDwnbMJCf89T1dvlhrFICVcBdbLqdpxdpj265NIV+zq3Pu9C3U55Pm/0HXEX4ukIK5mZmfQjZ8DGyK1bBv/EOCWSQmg== 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: 7c17ad1c-8bb4-46d5-75bf-08d7a357cc92 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2020 18:36:18.4577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2NAM12HT131 Subject: Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement From: tysonandre775@hotmail.com (tyson andre) > 1. Is it a typo that the first code example in the proposal has a=0A= > namespace declaration before the `declare` statement? Currently it is=0A= > a fatal error if a `strict_types` declaration isn't the first=0A= > statement in a file. Are you intending to change this restriction,=0A= > or have it not apply to the `function_and_const_lookup` declaration?=0A= =0A= Thanks, fixed. This statement order was wrong and from a previous revision = of the RFC.=0A= The restriction for `strict_types` won't change.=0A= =0A= > 2. How will this RFC fit into "future work on autoloading" (mentioned=0A= > as a benefit in the discussion section)? Would autoloading only be=0A= > possible for files with `declare(function_and_const_lookup=3D'global');`?= =0A= >=0A= > This RFC seems like a pragmatic attempt to solve the global/namespaced=0A= > ambiguity issue for the way code is typically written today (most=0A= > const/function uses in a namespace being global yet unqualified).=0A= > However, isn't the current lack of autoloading part of the reason for=0A= > this usage pattern? Personally I would love to write more plain=0A= > functions in namespaces, but am forced to use static class methods=0A= > instead to benefit from autoloading.=0A= =0A= A major objection to autoloading for functions and constants is that it's= =0A= unpredictable for ambiguous elements.=0A= (so one way to implement autoloading is to *only autoload if the reference = to a=0A= function or constant is unambiguous*)=0A= Right now, it's possible but inconvenient for projects to unambiguously ref= er to functions and constants,=0A= for the reasons mentioned in https://wiki.php.net/rfc/use_global_elements#i= ntroduction=0A= Implementing this RFC makes removing this ambiguity much easier.=0A= =0A= I wouldn't want autoloading to be limited to just files with function_and_c= onst_lookup=3D'global'=0A= =0A= > In other words, if PHP had function autoloading, there would be more=0A= > usage of namespaced functions, in which case changing function and=0A= > const lookup to global becomes less helpful. In this way the RFC seems=0A= > to work against one of its own goals.=0A= =0A= Yes, there would be more usage of namespaced functions.=0A= However, right now, most of the references to classes are to classes in dif= ferent namespaces.=0A= Most of the references to functions are in the global namespace,=0A= and of the references to functions outside of the global namespace,=0A= I'd guess that most are from a namespace *different* from the current names= pace.=0A= =0A= The other goal of this RFC is to make unambiguous references convenient.=0A= "[Manually using names from the global namespace] is prone to merge conflic= ts=0A= when functions start/stop being used, inconvenient to keep up to date,=0A= and the vast majority of the uses will be global functions and constants."= =0A= =0A= > I would find it quite annoying and counterintuitive to have to=0A= > explicitly `use` namespaced functions and consts in the same file=0A= > they are defined in. The example in the RFC of a function defined in=0A= > a namespace that appears to call itself but actually calls a different=0A= > global function is particularly confusing.=0A= =0A= Requiring `use function MyNS\sprintf;` before the declaration of a function= named `sprintf`=0A= outside of the global namespace is planned for the final version of this RF= C.=0A= Same for constants.=0A= =0A= - You can use `=3D'default'` or omit it in the files that declare functions= and constants=0A= if you don't want that.=0A= =0A= That example illustrates edge cases that had to be dealt with=0A= in the RFC's implementation, and I'd expect code like that to be uncommon.= =0A= =0A= Making the name resolution behavior easy to understand and not have surpris= ing special cases=0A= was the main reasoning for implementing it this way.=0A= It shouldn't matter which function gets declared first,=0A= whether functions are reordered when refactoring,=0A= or if the body of a function gets moved to a different file.=0A= =0A= > I'd really like to see a more complete proposal that thinks through=0A= > how it will fit in with future autoloading and the way people will=0A= > then write code, rather than just the way they write it today due to=0A= > current limitations.=0A= >=0A= > Long term I think it would be better to have a `declare(global_lookup=3D0= )`=0A= > option which could be applied to a set of namespaces, and a registered=0A= > function/const autoloader would only be triggered for those namespaces.= =0A= > This would allow function autoloading to be used without hurting performa= nce or breaking existing libraries.=0A= =0A= This was brought up in earlier discussion, in https://wiki.php.net/rfc/use_= global_elements#deprecate_fallback_to_the_root_namespace_instead=0A= Also see https://externals.io/message/107953#107962=0A= =0A= The "module system" idea also brought up the desire for a more complete pro= posal.=0A= Right now, though, a more complete proposal hasn't been created.=0A= =0A= Using `declare(global_lookup=3D0)` would not fix the current drawbacks of u= nambiguously=0A= referencing functions or constants that motivated me=0A= to create this RFC (in https://wiki.php.net/rfc/use_global_elements#introdu= ction)=0A= =0A= Thanks,=0A= - Tyson=0A=