On Friday, September 21, 2018 4:20:20 AM CDT Rowan Collins wrote: > 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.
Perhaps another disconnect here is that, in practice, the consumer of an object property is, in my experience, almost always "me". I almost never have public properties on my objects. On the rare occasion I do, it's for a "struct object" I'm using internally as a more self-documenting and memory efficient alternative to a nested associative array. In either case, if I fail to initialize a variable the only code that would be impacted is... my own, usually in the same class (or occasionally in a subclass). Finding the bug then is pretty straightforward, and it's my own damned fault, but therefore easy to fix. In my experience at least, most of the modern code I see in the wild is the same way. That means the potential impact of stray undefined properties roaming around the code base is really small. Even vaguely reasonably structured code already avoids this problem. I can't think of anything I've written in the last few years that wouldn't work this way, even with a constructor-exit-validation check, without any modification at all. Naturally if someone is using a lot of public properties in their code the potential for "undefined" bugs increases. That seems rather uncommon in my world, though. > > 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, Another benefit, since it would, I think, boil down to a series of isset() calls implemented in C land the performance impact is probably not measurable. (Obviously we'd need to measure that... :-) ) --Larry Garfield
signature.asc
Description: This is a digitally signed message part.
