Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:108298 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 33719 invoked from network); 28 Jan 2020 20:02:58 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 28 Jan 2020 20:02:58 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 62037180538 for ; Tue, 28 Jan 2020 10:13:25 -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.0 required=5.0 tests=BAYES_20,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 NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010033.outbound.protection.outlook.com [40.92.10.33]) (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 10:13:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h49S5ZuEabzZqukBhvDbrj+mN6VtJwOvp06QN+8WrZkw4CZXLNEogvBcxOlJNfndXhWJfkuxrDH2iIMDEtRtM8bkzIjYZ4RgsEy74xBpicVUJooEMv8mMlz3Oh6U2p1LcbhdlHXeYQgXNunHhc74K8AneVmsvbjmtG8cvO/xGf7JzB6LCT8v4Rn2jVhWjRrhwUZ7NE9Cpm8EMHiPuLQwDAq4rnEe+qVZm4ccS5Pso1rIsri+K60khnmqhdfGqKc/RVcD+ZFemOXVzkkBo1MugEItiFEUNeiiCvYCorAgBdt32wRQza/oPs6SV1crJfE/INow7KeFEPAUYa5b0hCkOg== 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=gypuM69/05vILF+0EAP7eruGeL7uT8c6wFTL/1Mc+/c=; b=RXnHOlSg+fOFWvi+LBmqG2sUckEvuRohNqtzaJQALtWCYrGn1HaCgxVtiGHVQym6tHOYJrGeZj0F5hSklwY1gfAUwVMHPilU/gziP9+tjXzbRyBKcXz7g48Dp/EEeTlREBjhMrV7CqhA6F+d73KV406ONNwcg4mQQ6ybiCa2IGfW6z5s/0HasicGy3jGvw6XqvWC4qtYKfyuDSuA9aOiHW5AlMvNRSqsRB/x3+kiH/kiMPTIUZ7gGv8F4PWC58hUHOQ7d1rJfZygXkjbK3kbNaYOAcTLQBS984+eORLVBJzubYcnCiUU7ZkRfj47+QY2mzfsq5SamNRBNgRB2EsQXg== 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=gypuM69/05vILF+0EAP7eruGeL7uT8c6wFTL/1Mc+/c=; b=neOLokU6DHbF4JqzDoe6ikYRmtJv6DlVF7gLGF2Z8ID+39sOsDUbZMx8wxp9OCRVgAqtYrbGp1yQTkTD7iYZixIx+h/iix7Kh1WPVRzCU+fWBB4d+Qqcp5X48BBL3EKNYRmIMa2tg3l2pmoqzxuXdglt6FQ5IJskqlDfSQBCgIS9ANz1IXGFWB4lxI/5AB2zfNrQUKhgJ0pwx/TYUrB7rwC7Xw8+sCWN7sqDvZ7vRzLksi0w2yvAes0R+Ana5VgYyRoxzK39/dYidSxe9pveau6u8CMCq81CqNQ7SPDcSHGJ1ZTWeO3JarTtZuzVGr+S4eLnuCWx5YH+PRzHpt7p7Q== Received: from CO1NAM04FT020.eop-NAM04.prod.protection.outlook.com (10.152.90.56) by CO1NAM04HT108.eop-NAM04.prod.protection.outlook.com (10.152.90.204) 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 18:13:23 +0000 Received: from DM5PR07MB3067.namprd07.prod.outlook.com (10.152.90.58) by CO1NAM04FT020.mail.protection.outlook.com (10.152.90.63) 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 18:13:23 +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 18:13:23 +0000 To: Rowan Tommins , "internals@lists.php.net" Thread-Topic: [PHP-DEV] [RFC] "use global functions/consts" statement Thread-Index: AQHV1IfBuqjWnIu9lEWrxlRKvYFij6f9dXecgADKhQCAAFMdqIAAWbgAgABUv12AAInJAIAAbhnXgAAYmgCAABHelA== Date: Tue, 28 Jan 2020 18:13:23 +0000 Message-ID: References: <2d50c8c0-cbd1-0a0e-4098-eb00facf86db@gmail.com> , In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:A156C0121750C4CB51DB712CDD2AEA26D63BA62FB141C42A50C707EDD5828B53;UpperCasedChecksum:1D5510F685285D087B5723108BC17C52C59998FB5F5B752528307C13AACE9243;SizeAsReceived:8151;Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [jqrTdYQInaMH4su/m3rVT6npkrG345ZW] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: a44489f2-fc55-462e-f2f4-08d7a41dc37d x-ms-traffictypediagnostic: CO1NAM04HT108: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qhSiDYdVSPWuUp1lwf5/1rPa2fpEjsHPuAZXcXUNF21n5/jAFQy2b9dQYTciEPxDVj4ttevO3dLDhc65vbgpc9VJfFS8fcfpaOm3p8W08/m7BQIu+yx62ijtyBABcUdls7wvh5B/r82IOwoEa+nTNsSLn/kckpGLVKUblnBeUGzl2giUXzZO17Mn7of3rs/L x-ms-exchange-antispam-messagedata: B6ghiCcrTddIivXpQnp8qhI5ID2o9SHdMOItHZHsOvx6+FBRuyIwQkV6Gpc7QHML2yyY7a/Yll6DLh9koP3ckxOeEFtQe1O4SEF9iaPY3IX3Js+7tyGEBVLYxDklinn7Koxmebm3//ogJgOuhpVkZg== 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: a44489f2-fc55-462e-f2f4-08d7a41dc37d X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2020 18:13:23.6652 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT108 Subject: Re: [PHP-DEV] [RFC] "use global functions/consts" statement From: tysonandre775@hotmail.com (tyson andre) > What do you mean by "weaker"?=0A= =0A= Any difference that might be expected by a user when for what differs=0A= between leaving out the setting and setting it to 'fallback'/'default'.=0A= =0A= E.g. in my example for `count`, a developer might expect `MyNs\count()`=0A= to continue working as `MyNs\count()` when they set the value to 'fallback= ',=0A= even when it became a keyword.=0A= =0A= > Let's flip those examples around: what if we want to make some magic=0A= > function always resolve to the current NS even in=0A= > function_and_const_lookup=3D'global' mode, or a particular cast be allowe= d=0A= > even in strict_types=3D1 mode? The two different modes for strict_types= =0A= > aren't even "old" and "new", they were both added at the same time, so=0A= > there's no reason one should have a stronger BC guarantee than the other.= =0A= =0A= That's more of an objection to 'global' than an argument about 'fallback' o= r 'default'.=0A= It isn't suggesting a name to use instead of 'global'.=0A= =0A= Any changes I don't expect to strict_types or function_and_const_lookup=0A= would be discussed in the RFCs proposing those changes.=0A= =0A= For allowing a particular cast with strict_types=3D1,=0A= only strict_types=3D1 would probably need to be changed to keep backwards c= ompatibility,=0A= since code without TypeErrors would continue to work.=0A= =0A= > Calling the mode 'default' won't stop people's code breaking if we change= =0A= > the resolution rules, and won't mean we can just ignore breaking changes,= =0A= > any more than if we hadn't added the mode switch in the first place. All = it=0A= > means is that if we change the default *mode*, it's unnecessarily difficu= lt=0A= > for people to migrate (see previous example scenarios).=0A= =0A= Preventing future RFCs from breaking code in small or large ways (or mitiga= ting it) I have no knowledge of=0A= is something I'd consider outside of the scope of this RFC.=0A= Those RFCs would have to plan for how users should be notified of and migra= te code=0A= when there are breaking changes to the defaults, whether or not function_an= d_const_lookup was added in this form.=0A= =0A= If 'fallback' and 'default' ever mean different things,=0A= we'll very likely need to add 'default' again if namespace-scoped declares = become a thing.=0A= So I'm adding 'default', and only 'default' for the RFC vote.=0A= =0A= > My worst fear is that we add this mode labelled as 'default', but actuall= y=0A= > tie it to the current behaviour, so that we eventually have a mode called= =0A= > 'default' that isn't the default. This happened to Wikipedia: they named= =0A= > their default skin 'standard', then regretted it when they changed the=0A= > default to be something else.=0A= =0A= I'm opposed to making 'default' become anything other than omitting the set= ting=0A= (from every place it could be set), and would want the fact that is intende= d to be the=0A= same as omitting it (for as long as possible) to be well documented.=0A= Of course, what you mention could still end up happening; I still consider = that unlikely.=0A= =0A= A 'fallback' can be added if and when we have a use case for it.=0A= =0A= There are large numbers of settings with values of 'standard'/'default' tha= t became problems.=0A= There are large numbers of settings with values of 'standard'/'default' tha= t made perfect sense=0A= and didn't cause any issues.=0A= =0A=