Hey Pedro, On Tue, May 26, 2020, 16:34 Pedro Magalhães <m...@pmmaga.net> wrote:
> Hi Marco, > > Thanks for the feedback. > > About the sealed type example, it is true that `final protected` wouldn't > achieve the same thing. But as an attempt to provide an alternative design, > wouldn't an union type of the desired children be a better choice? > Difficult without having type aliases for union types: possible with tools like psalm, but fragile and easy to work around for less experienced devs. The construct in my example is instead very hard to avoid unless you know about `ReflectionClass#newInstanceWithoutConstructor()` it is supported by a broken behavior > Not really: the `__`-prefixed methods are indirectly part of the object's API, and I seal them off by design, guiding consumers of my implementation & type. About lifting the restriction only to magic methods, I don't really like > that approach. Anything that makes them more special feels like a step in > the wrong direction. If we were to lift that restriction, I would say that > it should be lifted for any method, leaving the RFC to deal only with the > static and abstract cases. > Magic methods are indeed a pain in the language: I'm trying to make the best use for them (there's already enough bad usage out there). About the serialization example, I think that goal is equally possible to > achieve with final protected. > Good point! Considering that, as far as I know, only the constructor remains "special". >
