Am 21.04.2021 um 17:08 schrieb Andreas Leathley <a.leath...@gmx.net>: > On 21.04.21 15:14, Christian Schneider wrote: >> I never really understood the desire to restrict how people can use >> your code. >> If there is no good reason to override the value of a class constant people >> won't do it. >> If there might be a good reason (even one you as the original designer >> didn't predict) then why not leave that door open. >> >> While I understand the theoretical benefit of being able to specify this >> behavior I do think it is almost always counter productive and not a pattern >> I would encourage. Especially not in a dynamic language like PHP. > > Such restrictions also convey information and intent. One could argue > defining a specific return type to a method is restricting its use, but > it also clarifies how something should work and avoids unintended > changes.
To me, the term 'constant' is good enough for that... > final constants might be more niche, but it gives you a choice > on how you want a class constant to behave if child classes are > necessary and possibly done by someone else. ... but if child classes are necessary then how can you say that the constant's value should never be different for children? Why not leave that to the user of your class? I've seen my share of damage done by assumptions about how code will be used later. > Having "final" for constants seems a good addition to me, especially if > the inconsistent behavior with interface constants can be solved at the > same time. Fixing this inconsistency should be discussed separately IMHO. Both because it is a side-effect and should not be used as a reason to add 'final' as well as not fixing the problem for code *not* using 'final' with constants. Side-note: Back in my Java days people argued with performance to add 'final' but that only lead to it being sprinkled all over the place making code less flexible than it needed to be without real performance benefit. That's what I mean by promoting harmful patterns. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
