Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123569 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id A8F0A1A009C for ; Mon, 10 Jun 2024 17:51:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1718041953; bh=L/hfh8iSC7IIhS9KY0YXDiDlku3hfKbTJmauhay9sgQ=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=d9/U2sx+gBjHBaTFiTmKvbQ1W0iP8bI845jJxBDV79wsyn2F1AXugdl7oOyhaKlTF RnG2XZFY9zxkukOMX83iXBrj+SN3SA+c4aGeG/IpJdeLMP7fqEhpw1KLVvtDh8N3Ba I/OSIIVfIAEu1P8E8GS+PyQ4lT92rnKLM4RGhlu0ATWetUpvFC/t146mpvm/Sb5NdP sFT3E47f9fL31iFX3HhWT0E7dQHUNmMyB5d3sh1v7etOE5xw1wqeHfdEnehdNc0PvY R99e1aaAPB8+LOJFqtew7XPEEl+uPqSQY6T0U9tzpkSP2av/m9e0ob7ga7n10o3BYO fYHVYgx4cfwxQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id DB99318056A for ; Mon, 10 Jun 2024 17:52:32 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_50, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from BRA01-CPZ-obe.outbound.protection.outlook.com (mail-cpzbra01olkn2093.outbound.protection.outlook.com [40.92.97.93]) (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, 10 Jun 2024 17:52:32 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mq4aG3jMmDAqNnENusgK8WBCzzuVlgfgs0Ch5teyvA+iV+0OMipOqw2IoC5jEZJ4SVIL4AjM9OfBscOjJfldAVTN+aQMGEt8pJtGmfSjYDNjkvNM2iG/t/0Oul5EVPCaK7Hmp9bKQ6LlVn70nwyFu2isAPcNPi6n5cwtm6kqRs0hx8IdTEi1rb1Bqh6uBD1W0SPsj9TslB1yBshXw684hcVVouGelvJ7Z31dd3X2WykBmKJep2zYBIlI5v5CMvbOK8ofAwgOk9mQtBM3UMB3Yi/OAMjHb3Rp3cVbxS35tvP53NyksiZAUSMPp/h/uDeOIVKIUDqfN7S99hqahHAyLA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=L/hfh8iSC7IIhS9KY0YXDiDlku3hfKbTJmauhay9sgQ=; b=mywG33coaSnyy1+9Naf3mjPuqCf9zSv+nWGJVmOO9ykNKntgUF501dWXyQfi2lOC0CmCE066AotAazbXERc9Gwm89cgfEaqfyeDvhd5UkVEUxnpD6l6J58SUZDDpj/25iPflfbN888bnLYtXQJDG20+Rn+OhwlYJ39nd6vbgeLnezdhgnSmOOqlUshRADRrNRpKXn2HGhYC72xLO4wwqijA10lZrbotbEcBHvJyrZaJlk1lGNNRsvSqGvizldcpToP6S0rCv/g7CSZ3QdUJEnBspNS2jIf3XtVrj+g9HTv9MrsMx3s1X2uMQWT1uuJTKTJkUT4TweG0H47jO2tlYNw== 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=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L/hfh8iSC7IIhS9KY0YXDiDlku3hfKbTJmauhay9sgQ=; b=UkC3QpWokCwmZ09tO/AJGcxbAsyH3gWzKx/UmhpEN8mrG7qVh8rT5EYBv2vw841n9ACX/FtgrkBx50s/k29nNQC7KinFYD5rnjXxjrEeckwHW8DCOJqD8kA1DIwoe6NXMd0/msOff1+YnNezk6f8rvKR1cM8P/NQTlVdA3aqVAIiTY/Gz4UuOHI0kMv4LM2VuCq5pNyQwzSUTPfmTV1/RVyV3Pv8v2Mm1qVTiXiHOLLn9eAfEUZrf3NtwzkasjsJ9R5C4utk3n1YWNVYpzrq0k4K5VEFx3sdiqhWWdcSXJ9SKwUUtgGBO5JfMKGUJz9j9Rry51nVhuJerCHCPelg8w== Received: from CP8P284MB2148.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:1e4::5) by CP6P284MB1605.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:110::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7633.36; Mon, 10 Jun 2024 17:51:20 +0000 Received: from CP8P284MB2148.BRAP284.PROD.OUTLOOK.COM ([fe80::3914:749c:31bc:e96d]) by CP8P284MB2148.BRAP284.PROD.OUTLOOK.COM ([fe80::3914:749c:31bc:e96d%7]) with mapi id 15.20.7633.036; Mon, 10 Jun 2024 17:51:18 +0000 Date: Mon, 10 Jun 2024 14:51:07 -0300 To: Larry Garfield , Tiffany Cc: php internals Message-ID: In-Reply-To: References: <0a6a61cd-f203-4dea-a7f8-97e6b885c52d@app.fastmail.com> Subject: Re: [PHP-DEV] [RFC] Asymmetric Visibility, v2 X-Readdle-Message-ID: 9c1b1696-f4a0-4e59-a2fd-51c545fdf991@Spark Content-Type: multipart/alternative; boundary="66673d11_4d64ce3a_3324" X-TMN: [iG/B6xb6Ac19VK2HrnFS7mzfy8cFdC+j] X-ClientProxiedBy: CP5P284CA0195.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:22c::11) To CP8P284MB2148.BRAP284.PROD.OUTLOOK.COM (2603:10d6:103:1e4::5) X-Microsoft-Original-Message-ID: <9c1b1696-f4a0-4e59-a2fd-51c545fdf991@Spark> Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CP8P284MB2148:EE_|CP6P284MB1605:EE_ X-MS-Office365-Filtering-Correlation-Id: e9212af8-ae27-4481-99e9-08dc8975ee0c X-Microsoft-Antispam: BCL:0;ARA:14566002|9400799015|461199019|440099019|3412199016|1602099003|56899024; X-Microsoft-Antispam-Message-Info: 22mVjy8LGIPzD9/eJS//b2BboCcuZUGCRJ/3VXQDz0CSwnv9D/UkNTgm7dLepwL58FDyKspoGe4l0BXkDKC5b7rLpHI93UplylRRDCiaZpg6Lb9tp1UbbW0tBW7rZ3FjXatpZLzFCptgBdJqDW761/3DvO/KrrcpJi4FfxXjxEoRsAVwxMgAxGpoasobZx6Wsy+bU7bxn8xHFxpvvWf0GpeIwHoOKsPAT/ekyEDv89TPCkusvWJTGRG6c2CKGB8xjlyjh6yIoNs1lXILzO0mhRnKYIzLIUDG5pLVHSK9heojvQxtj/8HyWwry2gXbeIJZtuKkULw6yPJHk9AoreZBz3r6Yvo1dkXsGKbTi20ZYs9VyoI0WPrWGeefzYgOApFqsTjHHOM+rfxIkAiTHfpuhD+osyRzy1vLSSGKxUF0jX3a+V9cwSJ1AnCCNENGceOzQbPkux04qST+XUDxFsyIscKLixpdIS6zWr8BdHbsqRbreSdL1aapk7OeeCZNXHFdPKKikPmDjbUuYABTQeNydCeCivAUpakrbXO84Sa5zzTLljmRmsqzQVDnmt9WEATjeatWs4DSH7QTb0ka4Vqt/fCj2erh2X+mMJXX/LgyM5D2AmTrZrvdigwF7hEEkWkkuD5YCmG7Oc0R1y5h3rRytETeUSAPQXZfjaI3nW1Eq9u+bqETrn/SfKSu2OPWYT+G0GnFaQyOQrvEKAjCWO20n8bgOfCdcftID2f0jvpYLriYx59kiBF+FsDa/1DQfmG X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TFdpQnFpRVlMdnZEbmI4N2ZkNlZZYnhONFhKVldET1VFQlVkLzU0NXVHT3ZZ?= =?utf-8?B?d1l1TThSWmNhSUZpcWpQd0RKOTlpUk51bHNQbXN6MlVBb0J1RXgwNHRqRlVL?= =?utf-8?B?UEthUk85L1I3bk5nZUEzRFpFNVRzOHhLZ0N0aFlWTXl6dExYQk9WYUU2M0t6?= =?utf-8?B?dWR0aUNCS01sUGlYQlJ5WFJwTlVpWUw1ZHZTRER6ZUVqZUZrWkl2dDlpNWNW?= =?utf-8?B?NGxJekl4NW1rSC9iYjd4Wm53Tys2SmJNeEx4cVlmQzYyUU9SbDdJT0lYc0lM?= =?utf-8?B?RVRxTzhhWWZjMFB1S0VNZnQxcTVlYzZyRmQrM0pXaWxQYThKdW5iL0hzdjlH?= =?utf-8?B?N1JHWjVRSXI4bWp5ZFA0R2lwSlBha0xIa1V5T1NNVzQyeEFScXM0QTNyT3dX?= =?utf-8?B?ZU54UlNtaFAyU2xiQUJpcUVRMjdKSmlucU9Yb0txV2RlY0VwK1pRTHd2b2lT?= =?utf-8?B?MTlRT0luY0pvR3dqVkJxWVhTdlVjOG1nQmZGVytTU3BIYk8zeGZkVzFIU2x2?= =?utf-8?B?bzhKMllNV1lBVVBtL0duSkRsd2dxeGhOd2Q4UG93M2wxSWUvNkcxQTR0MTVD?= =?utf-8?B?alNkL1hRUHhBQXdpWlNObWVUbHlHMDBKZEFBeGtYN2gxRUtzdXdrSCtEZDZJ?= =?utf-8?B?a0pueUkzMjRkMVpmd2tiaSsvKzY5U21memIzRmJFSEFQRGVGbEJlbG80TEpJ?= =?utf-8?B?d0NJMXg1U20zK0hpRXZCYzY2TUxoZUUxRXNyR3h2eFgvakRKQ00xaGpDQ254?= =?utf-8?B?Z25EakJoVlBSRzJISy9ZeFIzaE0vN0lZb0pjM3QyRGhka29BaGNGNW1JcjFM?= =?utf-8?B?R25SSjd0ZFhtdUlvQW8wUE52ZzF4T0ZhcGlKSzV4bGw1cVFRb09FNnpKMzYv?= =?utf-8?B?dkVpV2s0ZUY0OFg2ZlY0bUxYQTk1UFduWE5OWkZFOFVHRVgvTEM5ZCs2SnpV?= =?utf-8?B?Vks0S1dPYVcvYzEzSG1ZcWE2SVg2b1NPN3Jra0MyR3VGT2dHM3dhbEpGYkhL?= =?utf-8?B?T3dsUHhWd1JWT2VPR1hGY05YanZQVnUwYUJwUTVaNmZmeTZrTDkxY0Z5bGhq?= =?utf-8?B?ZXJxekZRVEhJYytuN2lkVThuS1ROL0FjaTlOSW93eGhpU3k4YXFXanpaTEtV?= =?utf-8?B?dzZaUzZVSlJPdzRDRkIyK1FlZUZHaDdFejRXckJweCtlcjlYZ0Z1ODZxMVVF?= =?utf-8?B?V2ErQ3Q0eDJGQ3RTMkpweHJqV3BiS0lmTWk5ZThZeTdLblJoUnFKQXgxbWk2?= =?utf-8?B?dEpUV1ZXajdlOEkrUFhJelNlVUJlVVcrWCttM0NhWWN3M2JQSExhakF3d2hN?= =?utf-8?B?SFMvTm9sTXFTR3BwWm5pQjdpbGxDTlhnSk9XUlNxSWlnTHQyTndCZWloaFdP?= =?utf-8?B?ZXQ2eGQ2dkxCY25kbit5UE9HZW5pSkpSSVY3bUFEelo2aG1HMHZTZzM2enJI?= =?utf-8?B?bGtDQU5NeVpUUjZyTnRBdHVyTEZhRjdxVHlQcWxibXFEWUJScjBhMFg5cDlq?= =?utf-8?B?L2dZdVdXOU1jcnBSZ2taaUNHSG1tUGlja3JSUXVFVUVybzlyckJWcWxUOVYy?= =?utf-8?B?MG52MjZTKy9pR0o5eE02UUJrbHR0RDJFLzhweE9sMmNyTy8xMXExQ3ZQQmNR?= =?utf-8?B?Nmo1M2JhdkU0MTk4SjJ3RzVPbUdmb3pkbml0WEh1QTYvN1owdnA5TXdUT2VW?= =?utf-8?Q?tWI/DmISyWR0KxOX78mL?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e9212af8-ae27-4481-99e9-08dc8975ee0c X-MS-Exchange-CrossTenant-AuthSource: CP8P284MB2148.BRAP284.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2024 17:51:18.0613 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CP6P284MB1605 From: rodrigo.vieira92@outlook.com (Rodrigo Vieira) --66673d11_4d64ce3a_3324 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I didn't like the =60Prefix-style=60 syntax. I prefer the =60Hook-embedde= d-style=60 syntax. =46irst let's look at the counterpoints of the =60Pref= ix-style=60 syntax: =23=23 1) =22=60Prefix-style=60 is more visually scannable=22 > The set visibility is 10 lines away from the get visibility=21 Solution: =60=60=60php class HookEmbeddedStyle =7B =C2=A0=C2=A0 =C2=A0public string =24phone =7B =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0private set =7B =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=24this->phone =3D implode= ('', array=5Ffilter(fn(=24c) =3D> is=5Fnumeric(=24c), explode(=24value)))= =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=7D =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0get =7B =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (=21=24this->phone) =7B= =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return ''; =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=7D =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (=24this->phone=5B0=5D = =3D=3D=3D 1) =7B =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 'US '= . =24this->phone; =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=7D =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 'Intl +' . =24this-= >phone; =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=7D =C2=A0=C2=A0 =C2=A0=7D =7D =60=60=60 The set visibility is not 10 lines away from the get visibility if you pu= t it at the top. =46or me this is about code convention, not about syntac= tic structure: only put the hook with explicit visibility at the top, when some of the h= ooks do not have explicit visibility=21 =23=23 2) =22=60Prefix-style=60 is shorter=22 =60=60=60php public private(set) string =24name; public string =24name =7B private set; =7D =60=60=60 Irrelevant to consider 1-2 characters. If you break the lines needed for the hook block, the line (the horizonta= l size) is smaller when using =60Hook-embedded-style=60 and in my opinion= it is more readable because there is less information per line: =60=60=60php public private(set) string =24name; public string =24name =7B =C2=A0 =C2=A0private set; =7D =60=60=60 =23=23 3) =22=60Prefix-style=60 doesn't presume a connection with hooks=22= > As noted above in =22Interaction with hooks=22, visibility controls exi= st independently of hooks. I agree, but with Property Hooks, this should now define the overall visi= bility only. Like a bigger gate that you open, and there are other doors = defining the visibility of the operations get, set (hooks). > In fact, as implemented, they don't interact at all. Using hook syntax = for visibility controls is therefore surprising and confusing. Why =22surprising and confusing=22=3F I see hooks as a different kind of = function/method. Property Hooks R=46C shouldn't pass without requiring hook parentheses, f= or any hook when the property is not abstract. The =60=24value=60 in the = =60set=60 hook seems to come out of nowhere to some people (the exception= is for hooks declared on an abstract property which you can define witho= ut parameters and thus you are free to define whatever parameters you wan= t on the concrete property). When you define a method in PHP, it should be possible to omit the =22fun= ction=22, but the parameters should be required because that's the nature= of a function/method: to have parameters. =23=23 4) =22It's non-obvious in =60Hook-embedded-style=60 what hook beha= vior should be implied=22 > ...So =E2=80=9Carrays with hooks can do less=E2=80=9D is already an est= ablished fact of the language. However, if the hook-style syntax is used = for visibility: =60=60=60php class A =7B =C2=A0=C2=A0 =C2=A0public array =24arr =7B protected set; =7D =7D class B extends A =7B =C2=A0=C2=A0 =C2=A0public function add(int =24val) =C2=A0=C2=A0 =C2=A0=7B =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0// Should this be legal=3F =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=24this->arr=5B=5D =3D =24val; =C2=A0=C2=A0 =C2=A0=7D =7D =24b =3D new B(); =24b->add(5); =60=60=60 =46irst of all: non-abstract property hook must have a body. Second: when asymmetric visibility is explicit, it means that symmetric v= isibility is implicit: a declared hook that does not have declared visibi= lity has the same general visibility as the property, in this case: publi= c. Third: There's another limitation on hooks here that makes things a bit confusin= g: there's a missing hook for a specific operation because you can clearl= y separate the =60set=60 from the =60push=60 operation... Solution: =60=60=60php abstract class A =7B =C2=A0=C2=A0 =C2=A0abstract public array =24arr =7B =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0push; // Hook available only for =22arra= y=22 type properties only; public visibility =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0private set; =C2=A0=C2=A0 =C2=A0=7D =7D class B extends A =7B =C2=A0=C2=A0 =C2=A0public array =24arr =7B =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0push (=24value) =7B // =60public push ..= .=60 here is redundant =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Mandatory to implement = logic here. =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=7D =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0private set (=24value) =7B =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Mandatory to Implement = logic here. =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=7D =C2=A0=C2=A0 =C2=A0=7D =C2=A0=C2=A0 =C2=A0public function =5F=5Fconstruct () =C2=A0=C2=A0 =C2=A0=7B =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0// Legal =E2=9C=85 (set hook is protecte= d) =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=24this->arr =3D =5B1=5D; // call set ho= ok =C2=A0=C2=A0 =C2=A0=7D =C2=A0=C2=A0 =C2=A0public function add(int =24value) =C2=A0=C2=A0 =C2=A0=7B =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0// Legal =E2=9C=85 (push hook is public)= =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=24this->arr=5B=5D =3D =24value; // call= push hook =C2=A0=C2=A0 =C2=A0=7D =7D =24b =3D new B(); =24b->add(5); =24b->arr; // Legal =E2=9C=85 (Inherited from the general visibility that= is public) =24b->arr =3D =5B1, 2, 3=5D; // =46atal error =E2=9D=8C - access to set h= ook is private only =24b->arr=5B=5D =3D 4; // Legal =E2=9C=85 - call public push hook =60=60=60 My point: =60Prefix-style=60 is not future-proof =23=23 1) The =60Prefix-style=60 is not compatible with new hooks If more hooks are added in the future, such as the =60push=60 hook for ar= rays or even a hook that is compatible with all types such as =60init=60,= =60Hook-embedded-style=60 will become compatible, but =60Prefix-style=60= not. =23=23 2) Hook overloading If hook overloading is added in the future, =60Prefix-style=60 would not = be supported to have this granular visibility into operations. =46or exam= ple, it might be possible to add a public hook and a protected hook for t= he same operation, where one would be triggered if the operation occurred= from outside the class, and the other if the operation occurred from ins= ide the class. Em 10 de jun. de 2024 13:15 -0300, Tiffany = escreveu: > > > On Wed, May 29, 2024, 2:16=E2=80=AFPM Larry Garfield wrote: > > > As promised, Ilija and I offer this revised version of asymmetric v= isibility. > > > > > > https://wiki.php.net/rfc/asymmetric-visibility-v2 > > > > > > It's still essentially the same as last year's version, but with a = few adjustments and changes: > > > > > > * readonly properties are now supported in a logical fashion. > > > * We've brought back the abbreviated form, as public-read, somethin= g else set is the most common use case. > > > * The section on magic methods has been greatly simplified.=C2=A0 T= he implementation itself hasn't changed, but the explanation is a lot les= s confusing now. > > > * We've explained how aviz interacts with hooks (they don't, really= ) and with interface properties (in the obvious way), which didn't exist = at the time of the last draft. > > > * We've added a section with examples of how aviz is a concrete imp= rovement, even in a world with readonly and hooks. > > > * We've added a section discussing why the prefix-style syntax was = chosen. > > > > > > *dons flame retardant suit* > > > > > > -- > > > =C2=A0 Larry Garfield > > > =C2=A0 larry=40garfieldtech.com > > Sending an email to quickly enable a new mailing list subscriber to eng= age in the conversation. --66673d11_4d64ce3a_3324 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I didn't like the `Prefix-style` syntax. I prefer the `Ho= ok-embedded-style` syntax. First let's look at the counterpoints of the `Pr= efix-style` syntax:

## 1) "`Prefix-style` is more visually scannable"
> The set visibility is 10 lines away from the get visibility!

Solution:
```php
class HookEmbeddedStyle
{
    public string $phone {
        private set {
            $this->phone =3D implode(= '', array_filter(fn($c) =3D> is_numeric($c), explode($value)))
        }
        get {
            if (!$this->phone) {
                return '';
            }
            if ($this->phone[0] =3D= =3D=3D 1) {
                return 'US ' .= $this->phone;
            }
            return 'Intl +' . $this->= phone;
        }
    }
}
```
The set visibility is not 10 lines away from the get visibility if you put = it at the top. For me this is about code convention, not about syntactic st= ructure:
only put the hook with explicit visibility at the top, when some of the hoo= ks do not have explicit visibility!

## 2) "`Prefix-style` is shorter"
```php
public private(set) string $name;

public string $name { private set; }
```

Irrelevant to consider 1-2 characters.
If you break the lines needed for the hook block, the line (the horizontal = size) is smaller when using `Hook-embedded-style` and in my opinion it is m= ore readable because there is less information per line:
```php
public private(set) string $name;

public string $name {
   private set;
}
```

## 3) "`Prefix-style` doesn't presume a connection with hooks" > As noted above in "Interaction with hooks", visibility contr= ols exist independently of hooks.

I agree, but with Property Hooks, this should now define the overall visibi= lity only. Like a bigger gate that you open, and there are other doors defi= ning the visibility of the operations get, set (hooks).

> In fact, as implemented, they don't interact at all. Using hook syntax= for visibility controls is therefore surprising and confusing.

Why "surprising and confusing"? I see hooks as a different kind o= f function/method. 
Property Hooks RFC shouldn't pass without requiring hook parentheses, for a= ny hook when the property is not abstract. The `$value` in the `set` hook s= eems to come out of nowhere to some people (the exception is for hooks decl= ared on an abstract property which you can define without parameters and th= us you are free to define whatever parameters you want on the concrete prop= erty).

When you define a method in PHP, it should be possible to omit the "fu= nction", but the parameters should be required because that's the natu= re of a function/method: to have parameters.

## 4) "It's non-obvious in `Hook-embedded-style` what hook behavior sh= ould be implied"

> ...So =E2=80=9Carrays with hooks can do less=E2=80=9D is already an es= tablished fact of the language. However, if the hook-style syntax is used f= or visibility:

```php
class A
{
    public array $arr { protected set; }
}
 
class B extends A
{
    public function add(int $val)
    {
        // Should this be legal?
        $this->arr[] =3D $val;
    }
}
 
$b =3D new B();
 
$b->add(5);
```
First of all: non-abstract property hook must have a body.
Second: when asymmetric visibility is explicit, it means that symmetric vis= ibility is implicit: a declared hook that does not have declared visibility= has the same general visibility as the property, in this case: public.

Third:
There's another limitation on hooks here that makes things a bit confusing:= there's a missing hook for a specific operation because you can clearly se= parate the `set` from the `push` operation...

Solution:
```php
abstract class A
{
    abstract public array $arr {
        push; // Hook available only for "arr= ay" type properties only; public visibility
        private set;
    }
}

class B extends A
{
    public array $arr {
        push ($value) { // `public push ...` here = is redundant
            // Mandatory to implement lo= gic here.
        }
        private set ($value) {
            // Mandatory to Implement lo= gic here.
        }
    }

    public function __construct ()
    {
        // Legal =E2=9C=85 (set hook is protected)=
        $this->arr =3D [1]; // call set hook     }
    public function add(int $value)
    {
        // Legal =E2=9C=85 (push hook is public)         $this->arr[] =3D $value; // call push h= ook
    }
}

$b =3D new B();

$b->add(5);
$b->arr; // Legal =E2=9C=85 (Inherited from the general visibility that = is public) 
$b->arr =3D [1, 2, 3]; // Fatal error =E2=9D=8C - access to set hook is = private only
$b->arr[] =3D 4; // Legal =E2=9C=85 - call public push hook
```

My point: `Prefix-style` is not future-proof
## 1) The `Prefix-style` is not compatible with new hooks
If more hooks are added in the future, such as the `push` hook for arrays o= r even a hook that is compatible with all types such as `init`, `Hook-embed= ded-style` will become compatible, but `Prefix-style` not.

## 2) Hook overloading
If hook overloading is added in the future, `Prefix-style` would not be sup= ported to have this granular visibility into operations. For example, it mi= ght be possible to add a public hook and a protected hook for the same oper= ation, where one would be triggered if the operation occurred from outside = the class, and the other if the operation occurred from inside the class.
Em 10 de jun. de 2024 13:15 -0300, Tiffan= y <tiffany.k.taylor@gmail.com> escreveu:

On Wed, May 29, 2024, 2:16=E2=80=AFPM= Larry Garfield <larry@garfiel= dtech.com> wrote:
As promised, Ilija and I offer this revised = version of asymmetric visibility. 

https://wiki.php.net/rfc/asymmetric-visi= bility-v2

It's still essentially the same as last year's version, but with a few adju= stments and changes:

* readonly properties are now supported in a logical fashion.
* We've brought back the abbreviated form, as public-read, something else s= et is the most common use case.
* The section on magic methods has been greatly simplified.  The imple= mentation itself hasn't changed, but the explanation is a lot less confusin= g now.
* We've explained how aviz interacts with hooks (they don't, really) and wi= th interface properties (in the obvious way), which didn't exist at the tim= e of the last draft.
* We've added a section with examples of how aviz is a concrete improvement= , even in a world with readonly and hooks.
* We've added a section discussing why the prefix-style syntax was chosen.<= br>
*dons flame retardant suit*

--
  Larry Garfield
  larry@garfieldtech.com

Sending an email to quickly enable a new mailing list sub= scriber to engage in the conversation.
--66673d11_4d64ce3a_3324--