On Mon, Dec 5, 2022, at 12:47 PM, Claude Pache wrote: >> Le 3 déc. 2022 à 19:28, Larry Garfield <la...@garfieldtech.com> a écrit : >> >> I also clarified that static properties are explicitly not supported with >> a-viz. > > This is a serious issue, not necessarily because it is of great value, > but because it introduces an unexpected asymmetry between static and > non-static properties. In other words, from a user point-of-view, it is > expected that staticness is orthogonal to visibility. > > Therefore, I would expect that the RFC has a dedicated section about > static properties (as it has already one about [un]typed properties), > not just a small sentence in the intro that could be overlooked. > > >> and as it's of limited value we're not going to bother. > > Whether it’s of limited value or not, depends, I suppose, of coding > style. Personally, I use static properties for various good and bad > reasons, and some of them would be happy to take advantage of > asymmetric visibility. E.g.: > > * I may store settings that concern the whole class (and that I cannot > or want not register as constants) in static properties; > > * My typical implementation of “monostate pattern” is not: > `Foo::getInstance()->bar()`, `Foo::getInstance()->baz`, but: > `Foo::bar()`, `Foo::$baz`; > > * ... > > Of course, I would accept the reason “it is difficult to implement”, > but not the excuse “it is almost worthless”.
It is difficult to implement, and thus we're not going to put in the effort to figure out how to do it because the value is so much less. :-) But fair enough, I'll move it to its own section so it's more readily apparent. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
