Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108134 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 15438 invoked from network); 15 Jan 2020 02:07:23 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Jan 2020 02:07:23 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 9A21D180504 for ; Tue, 14 Jan 2020 16:14:24 -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=-0.5 required=5.0 tests=BAYES_05,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-SN1-obe.outbound.protection.outlook.com (mail-oln040092005014.outbound.protection.outlook.com [40.92.5.14]) (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, 14 Jan 2020 16:14:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K2iJUCpPYKYK8e23a3+/4vbOuOTtXQW41KttjFh7c12NgtaWS8ycXa/jZv8/Ig10tO01qYmWYXse3gKNWQCt97iXXSpMtcffNmJBksfIClNrLkMz3JPkBlGibKZgDFVczBuIcx6aBvgIRLZAfcGiEykc3HiDaZb6jwFUFlMoy7O6PsPytIPbyaqvRbO0tDW8EYPovgQe55f5O15bNeccJ+vJMOsd+NULFgzpTsmynstSJS/sWeSDKqAF4a1/m7QBcuda9MDzXnOy9hqVcgBi+hGM7Mvr+85/h14SCcsLwecGB/tilGjh7Le5hGcJo7Q7I70c1RgAXQRyZ8kk1Sn+gA== 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=wIz5qvNqmOEXRlJVfLYbkTTDduHeDUGZBFEV+K3pBjE=; b=IDYzW81dWKq5uO5OmKDqZ05Nrz+IHjf6+iOBlb3CxXaMxOyOzI3lA2NOOxu1yicr5kphib1U/VZAVckLNr1oeNDKTgRVM8hnQU+MWJg0X5/cv8AAbcTPwZxiXQpFOeB4asDvJLdtzSK7Cgn6N2B6ttrKmYuqiPEBZ1Ui+a3WLRIftZ2MoPzJjdcchj7EfuqEmqx4DihHHflCm41LLMcAGFIZMDY7DXNXxm/T8/TD1dI3KryfEmxA+mG1+MHH9U8Ux71P1l+rIEt2jw2RBqhidGp/qUoz6gIGO2SvbSbY024vgCIHPl3bRKuwDYMVZ94j8d2jL041PsKM/XSxqNBIcQ== 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=wIz5qvNqmOEXRlJVfLYbkTTDduHeDUGZBFEV+K3pBjE=; b=m8PnCJ+M93aNyCrmjJMcrF5sacPQld8jT2dAN3TSLDuVGQ2zkU0QIuDtUi2pyZiepuL/1ZFMUHYCRgc7dCKBgOCalQEcBhpq2JzcM8rqs7hJo5L6BIxUtZ3MpV6lYe7eTeb8MGHZSkS+FOJlAHhacjnvdIMlbJG6rX3du4Xn6gBkOR+t4/Dpy1hkfdoMWe4dpt/cpti3UZXcWwNuA0LsuegigZM3TNxAt6gkZaU+9RVz4Isr+8aN4pPtkNAR6eTqXN521JF46uoqa6vmI1Hv2Rr8wWOyk2ytkTkgFzzshCcxczdsKjTrrTCy35KI34Sv9FKgQHcG8+yzl1N5w1Z+jw== Received: from SN1NAM02FT061.eop-nam02.prod.protection.outlook.com (10.152.72.54) by SN1NAM02HT059.eop-nam02.prod.protection.outlook.com (10.152.73.45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Wed, 15 Jan 2020 00:14:22 +0000 Received: from DM5PR07MB3067.namprd07.prod.outlook.com (10.152.72.52) by SN1NAM02FT061.mail.protection.outlook.com (10.152.72.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9 via Frontend Transport; Wed, 15 Jan 2020 00:14:22 +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.2644.015; Wed, 15 Jan 2020 00:14:22 +0000 To: Nikita Popov CC: "internals@lists.php.net" Thread-Topic: [PHP-DEV] Re: [RFC] "use global functions/consts" statement Thread-Index: AQHVwNgGtev425C1jEaW2/fYCDQJoKfqjUCogAA6vwCAABZSCA== Date: Wed, 15 Jan 2020 00:14:22 +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:2EC2CAD9A1F6EEAEE52AF9B5E270E64FB1313F1E5FEA86135D73CABD8F8A39C4;UpperCasedChecksum:952543D08F7157B71E183A239C06671784BF567EF264DDA945B25745D2C049DE;SizeAsReceived:7349;Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [qabpFDHd+haDvyO0tmliW42YiEH3amdSJyGsbi9j4SybrDktyWUUIBkhT+gE+945] x-ms-publictraffictype: Email x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: e81b806e-503e-4031-f8a8-08d7994fdf52 x-ms-traffictypediagnostic: SN1NAM02HT059: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Vs7AQOr7HJrtGjiZkJvreLIm6wQUiFN6q7EgRjsii7Dxr5ZbeyTKNOjX1MmIMI7oYTmDOinbRZjfHYwTG4GpNyrkYElOAaFgRZP33NdoB6NoxhBfLGjmSz63bqjwI4iXr1xJjFIQuTpaUO93V8AvvpmFiE8P0gdwVDP9n74pPYjFN7/1pIgV26XvvgvSokJrKJ722sc30BIeGl/aVAp/yas8DzGcJ3YBAXhvoAuUOW8= 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: e81b806e-503e-4031-f8a8-08d7994fdf52 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2020 00:14:22.3287 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT059 Subject: Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement From: tysonandre775@hotmail.com (tyson andre) I'll be postponing the vote to update the RFC and proof of concept/tests as= sociated with it to use declare()=0A= =0A= Also, "declare(lookup_functions_in_current_namespace =3D false, lookup_cons= ts_in_global_namespace =3D false)" in the file's declare() blocks was my fi= rst idea.=0A= Any ideas - declare(disable_ambiguous_element_lookups=3D1), declare(disable= _ambiguous_lookups_in_current_namespace=3D1), etc?=0A= =0A= x=3D1 seems to be more common, and reflects the fact that this is not the d= efault.=0A= =0A= > I don't think it's a good idea to resolve the question of "use global fun= ctions" vs "declare" as a subsidiary vote.=0A= > At least in my mind, those two options are significantly different, and t= his choice would affect both my overall opinion of the proposal=0A= > and also the answer I would give on some of the other voted question.=0A= =0A= Agreed, I had some of those concerns after suggesting setting it up that wa= y.=0A= It doesn't capture "accept if one option, but not if the other option".=0A= =0A= =0A= Ideally, I could have a vote for the syntax to use for the RFC,=0A= then amend the RFC with the syntax, but that isn't practical.=0A= =0A= > The RFC already outlines a number of reasons why it is preferable to impl= ement this as a declare directive,=0A= > so please excuse my reiterating some points here :)=0A= > First and foremost, if we ever implement =0A= https://wiki.php.net/rfc/namespace_scoped_declares or some similar way of s= pecifying declares on the package level,=0A= > and I think it's pretty likely that we're going to do this in one form or= another, then we're very much going to regret not making this a=0A= declare.=0A= > Disabling the namespace fallback, just like the use of strict types, is s= omething you will usually want to do for an entire library/project, not jus= t for individual files.=0A= > Going for something like "use global functions" preemptively precludes th= is for no good reason.=0A= =0A= That's a good point. I think that's the first time I've seen that RFC.=0A= https://wiki.php.net/rfc/namespace_scoped_declares#nesting_behavior / =0A= https://wiki.php.net/rfc/namespace_scoped_declares#implementation_considera= tions answers my questions about how that would work with readability/opcac= he.=0A= =0A= It'd definitely be convenient to have less boilerplate.=0A= =0A= > Second, I think phrasing the semantics in terms of a change to name resol= ution behavior (which the declare does)=0A= > is clearer than phrasing it as "import all functions/consts in the global= namespace".=0A= > That's not really what this this feature is doing on a technical=0A= level, and this phrasing is what results in questions regarding the behavi= or for various conditions regarding symbol overlaps etc.=0A= > For example, with the declare, I don't think that it should be an error t= o make a function declaration inside a namespace=0A= > -- that's still entirely well defined, and I think a legitimate use-case= =0A= > (a project that is disabling namespace fallback everywhere, will likely w= ant to do that for files declaring functions as well, as a matter of consis= tency.)=0A= =0A= My concern was about this being well-defined but being likely to be acciden= tally misused, e.g. with namespace-scoped declares.=0A= Same for NS\my_printf calling \my_sprintf instead of NS\my_sprintf within t= he same file.=0A= Explicitly changing to namespace\my_sprintf() or uses would be one way to m= igrate code like that.=0A= =0A= namespace Example;=0A= use global functions; // or declare()=0A= // interpreting this literally, without `use Example\fact;` instead of = namespace\fact, this is calling \fact(), which is surprising=0A= // (the old equivalent `use function fact;` would throw because of the = name reuse) =0A= function fact($n) { return $n > 1 ? $n * fact($n - 1) : 1; }=0A= =0A= =0A= > Third, I'm not sure it makes sense to separate this functionality for fun= ctions and for constants.=0A= > I can't really imagine a situation where you would want to, say, use name= spaced constants but global functions.=0A= > I can see why you went with this split when using the "use" syntax (as we= already have "use function" and "use const" both),=0A= > but with a declare approach, I would suggest to combine both. Functions a= nd constants live in different symbol spaces,=0A= > but their name resolution behavior is the same.=0A= =0A= If you're declaring a function or a constant in a namespace, the way I impl= emented it would throw an Error at compile time to avoid confusion.=0A= If it didn't throw an Error, then I'd agree that it'd virtually always be u= sed together, except possibly when migrating to being stricter gradually.= =0A= =0A= > Finally, if you do want to go with the "use" syntax, "functions" and "con= sts" should not be made reserved keywords.=0A= > There is no technical need for these to be true keywords, so we can avoid= an unnecessary BC break here.=0A= =0A= Agreed for future work on "use"=