On Mon, Mar 16, 2020, at 6:57 AM, Nicolas Grekas wrote: > Le lun. 16 mars 2020 à 12:52, Máté Kocsis <kocsismat...@gmail.com> a écrit : > > > > > > > The other one is the recently declined > > > https://wiki.php.net/rfc/object-initializer. As it basically works by > > > first > > > creating the object normally (including a possible constructor call), and > > > then assigning the specified properties, this would not be compatible > > with > > > readonly properties that have defaults. Other implementation approaches > > are > > > possible though, but may not be easily reconcilable with the need to also > > > call the constructor. > > > > > > > I think what I'd expect from a possible object initializer feature is that > > it > > can't overwrite "write-once" properties with default values. (?) > > > > However, I'm ok to to remove support for default values because of the > > possible > > problems outlined (confusion for end users, uncertainty how it'd work > > together with new > > features etc.). It seems that the replies are more on this side, so let's > > be a bit more > > conservative than I originally wanted to be, so that we have more freedom > > later. > > > > Actually, I have already updated the RFC with this. Also, I made some > > clarifications > > in connection with serialization and the usage of resources. > > > > > I repeat what I wrote before but all those problems would disappear if we > were to bind the proposal to visibility: > https://externals.io/message/108675#108753 > > We could even consider splitting "read" and "write" in two separate > keywords, each bound to visibility, isn't it?
How would 2 separate keywords work, syntactically/visually? I can see how it would solve a larger cluster of use cases, but I'm not sure what the code would look like. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
