On Thu, 20 Sep 2018 at 16:52, Larry Garfield <la...@garfieldtech.com> wrote:
> I think the distinction here is that one group is arguing for "state of > the > data assertions" while the RFC as implemented is "setter assertion > shorthand". > That is, it doesn't assert that a value IS a given type, but that it can > only > be SET TO a given type. > > I don't think a complete IS enforcement is possible given PHP's nature. > ... > That hasn't brought about the end of the world, so I'm not super worried > about > imperfect property checks destroying everything. > > That said, I totally appreciate the desire as a consumer of an object to > know > that it's read-type-safe. This is a useful distinction, thank you for putting it so clearly. Perhaps it depends whether you are looking at the feature as a library author, or a library consumer: as an author, you want to protect "your" objects from invalid *assignments*, inside and outside the library; as a consumer, you want assurance that you can *use* the object in a particular way. The current implementation provides a good tool for the author, but falls short for the consumer. > To wit, could we add an engine check to scan an object and make sure its > objects are all type valid right-now (viz, nothing is unitialized), and > then > call it on selected actions automatically and allow users to call it at > arbitrary times if they are doing more esoteric things? > > I'm thinking: > > * on __construct() exit. > * on __wakeup() exit. > * Possibly other similar checkpoints. > * When a user calls is_fully_initialized($obj); (or something) > > is_fully_initialized() would return bool. The other checkpoints would > throw a > TypeError. > > That would layer on top of the current RFC cleanly, would give us the read- > assurance that we'd like in the 95% case I think this is a really sensible approach: as you say, it may never be possible to assert the invariant in every case, so checking the most common scenarios may be the pragmatic thing to do. Conveniently, treating it as an occasional assertion, rather than a strict invariant, means we can keep the unset() lazy-initialization hack; it's still an odd feature IMO, but probably not all that likely to be triggered by mistake. Regards, -- Rowan Collins [IMSoP]
