/Sending this again because the mail server was down./ +1 from my side too for this proposal. Retrofitting immutability with additional keywords is not the nicest thing but PHP has no other way (same was true for Java when they added it).
Using the *final* keyword while subclasses are able to override it is
ambiguous in PHP because it already has the notion that something is not
extensible (class) or overridable (method). Hence, I would either use a
different keyword or implement two keywords (and two RFCs):
1. *immutable* for the functionality you are currently working on.
2. *sealed* for the above plus type not changeable.
3. *final* for the above plus not being overridable.
Opening restrictions should be possible as with widening visibility in
inheritance but making something more tight should not because it would
violate the (implicit) interface of the parent class. In other words:
OK
==
immutable -> mutable
sealed -> immutable
sealed -> mutable
Fatal Error
===========
immutable -> sealed
immutable -> final
sealed -> final
final -> immutable
final -> sealed
final -> mutable
mutable -> immutable
mutable -> sealed
mutable -> final
Of course it would be nice to have the possibility to disable these
restrictions while creating fakes, mocks, ... in unit tests. Sadly that
is a feature that we don't have at all in PHP; e.g.:
final class ClassUnderTest {}
mock class TestDouble extends ClassUnderTest {}
I do not think that there should be anything that prevents this new
feature to work nicely together with typed properties. Of course I could
be wrong here but then again it might only require a few adoptions of
that feature to work nicely. One thing is for sure, *immutable*,
*sealed* and *final* would also disallow references (e.g. sorting of an
array); which is a good thing.
--
Richard "Fleshgrinder" Fussenegger
signature.asc
Description: OpenPGP digital signature
