On Wed, Jun 9, 2021, at 5:05 AM, Pierre Joye wrote: > Hi Nikita, > > On Fri, Jun 4, 2021 at 10:19 PM Nikita Popov <nikita....@gmail.com> wrote: > > > > Hi internals, > > > > I'd like to open the discussion on readonly properties: > > https://wiki.php.net/rfc/readonly_properties_v2 > > Very good work, thank you :) > > > This proposal is similar to the > > https://wiki.php.net/rfc/write_once_properties RFC that has been declined > > previously. One significant difference is that the new RFC limits the scope > > of initializing assignments. I think a key mistake of the previous RFC was > > the confusing "write-once" framing, which is both technically correct and > > quite irrelevant. > > > > Please see the rationale section ( > > https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this > > proposal relates to other RFCs and alternatives. > > About this paragraph in > https://wiki.php.net/rfc/readonly_properties_v2#rationale: > > " The addition of readonly properties neither precludes nor > discourages the addition of asymmetric property visibility." > > To me this sentence is the meaning of a readonly property, not an > immutable property, as in writeable once property, in constructor. > > This RFC is perfect given its goal but the property attribute "readonly". > > How would you define a property only readable from outside the scope > but writeable inside the scope of its class (->status f.e.)? > > This is PHP and we always have our ways. That being said, the keyword > "readonly" is really about what is defined as "asymmetric property > visibility" in many other languages. Rust uses annotation, .net via > either readonly and they use an init setter to make it immutable in > v9 (public DateTime RecordedAt { get; init; }), other like java or > scala relies on setting a property getters only. > > Given this, I wonder if it would not be easier to have actual per > property getter/setter as an addition or replacement to the current > (kind of horrible) get/set($name, $value). This would all cases in > one shot, a more complicated shot but much more powerful. For the > record, I am totally not a fan of the 'manual" get/setMyProperty ;) > > In any case, I would at least put a second thought on the name "readonly". > > ps: sorry if this question has been discussed in previous RFCs, > pointers appreciated as I did not find it :) > > Best, > -- > Pierre
Pierre and Mike: "Asymmetric visibility" as we keep referring to it would mean the "implicit accessors only" version of this: https://wiki.php.net/rfc/property_accessors That is, it would let you define public/private/protected for get and set operations on a property separately from each other. There are three key differences between readonly and asymmetric visibility as described there: * Asymmetric visibility would allow a property to be reassigned multiple times from within a class, readonly would allow writing to it only once when it's uninitialized. Whether one of those is too-tight or too-loose is a matter of opinion and context. * Asymmetric visibility is deliberately a syntax that is forward-compatible with explicit accessor methods in the future. readonly would be a separate, independent feature/syntax. * Asymmetric visibility, IMO, is a stand-alone useful feature. readonly would be most useful if combined with a separate clone-with operator (discussed elsewhere). Whether readonly is useful enough on its own without that to justify its passage without a clone-with RFC also under discussion is an open question, and largely what we've been debating. Both approaches would eliminate *most* uses of __get/__set, which I think everyone agrees is a win. (Nikita, I hope I represented that accurately.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
