Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110788 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 75349 invoked from network); 29 Jun 2020 21:05:44 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 29 Jun 2020 21:05:44 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A69A518056C for ; Mon, 29 Jun 2020 12:54:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS24940 116.202.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 29 Jun 2020 12:54:27 -0700 (PDT) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id EB0D360F5E for ; Mon, 29 Jun 2020 19:54:24 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freedom.nl; s=default; t=1593460464; bh=EoXwC74hMZ59Yg3CKPFDqwaQJe8fATwlw5nW/X8XDvU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=wigQsu3qKf47+VTpR3hooe1U6Jw713TZlu3bxHK4KKmbf5EYF++ypqGMje4Xp1Xn6 XMdOkSWcJod92gnjLS++TXTaA24aYWrdGjCSKrR3hxPCf+KbusJLgijIRIx20C1L1I 3DILsOu/m8XAgfNdUruNSAbGJtC8/isd0T3Fr0aA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=freedom.nl; s=default; t=1593460464; bh=EoXwC74hMZ59Yg3CKPFDqwaQJe8fATwlw5nW/X8XDvU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=wigQsu3qKf47+VTpR3hooe1U6Jw713TZlu3bxHK4KKmbf5EYF++ypqGMje4Xp1Xn6 XMdOkSWcJod92gnjLS++TXTaA24aYWrdGjCSKrR3hxPCf+KbusJLgijIRIx20C1L1I 3DILsOu/m8XAgfNdUruNSAbGJtC8/isd0T3Fr0aA= To: =?UTF-8?B?QW5kcsOpIFLDuG1ja2U=?= , PHP Internals List References: Message-ID: <49219ad7-124f-6b95-b691-984c69f8a1d8@freedom.nl> Date: Mon, 29 Jun 2020 21:54:23 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Virus-Scanned: clamav-milter 0.102.3 at c03mi01 X-Virus-Status: Clean Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC] Property write visibility From: d.h.j.takken@freedom.nl (Dik Takken) On 29-06-2020 11:41, André Rømcke wrote: > Good morning Internals, > > I'd like to start discussion on a new RFC proposing a way to be able to > (optionally) specify property > write visibility, separate from read: > > https://wiki.php.net/rfc/property_write_visibility Perhaps another option could be to use attributes: <> public int $id; Assuming named arguments get accepted as well, we could use optional arguments to specify special behavior by writing: <> public int $id; These optional arguments could also be introduced later using a followup RFC, after introducing a basic ReadOnly attribute. This attribute-based approach could be extended later to implement property accessors. That would provide property accessors similar to how it is done in Python: <> public function someValue(): int { return $this->someValue; } which could then be accessed as: $instance->someValue The above accessor method would be the equivalent of: <> public int $someValue; That makes the ReadOnly attribute a short hand for the Property attribute. This short hand is something that Python does not have, by the way. Using accessor attributes to create a writable property could look like this: <> public function someValue(int $newValue) { $this->someValue = $newValue; } Making the property writable only in the protected or private scope could be done by using the existing mechanism of declaring the accessor method as protected or private. So perhaps an attribute-based approach provides a nice alternative path for gradually improving object ergonomics. Regards, Dik Takken