I agree that what you say conceptually makes sense; however, in a pragmatic world we usually deal with a single User class, and at some point we might want to optimize a script that was accepting a User object, but was only using, say its id and name. Doctrine already allows this, with a caveat: https://www.doctrine-project.org/projects/doctrine-orm/en/2.6/reference/partial-objects.html
You usually know where you loaded your User anyway; plus, it will still be easier to debug an uninitialized property Error that will occur straight away, rather than a null reference that can be passed along before erroring somewhere else. But we digress, can we focus on whether to add another isset()-like construct, or a property_is_initialized() function, ideally with a companion opcode to speed it up? Thank you, Ben On Wed, 6 Feb 2019 at 18:38, Rowan Collins <rowan.coll...@gmail.com> wrote: > On Wed, 6 Feb 2019 at 15:21, Benjamin Morel <benjamin.mo...@gmail.com> > wrote: > >> You're right, in most of the cases properties SHOULD be set by the >> constructor. I do find the current behaviour interesting, however, from a >> data mapper point of view: you might want to retrieve a partial object from >> the database, and get an Error if you accidentally access an uninitialized >> property, as opposed to the pre-typed properties era, where you would get >> null and the "error" would be silenced. >> > > The problem with that is, the code doing the partial loading might be > thousands of lines from the code "accidentally" accessing the property. If, > for example, a User class supported partial loading of this sort, any > function that takes a User would have to handle the possibility that what > was actually passed was a partial User. If an error was raised, it would > require tracing back through the code to work out where the conversion from > partial to full object should have happened. > > A cleaner implementation would have PartialUser as a different type, which > could not be passed to a function expecting a User; it would then be clear > that a specific code needed to perform a conversion to fetch the rest of > the data, e.g. function getUserFromPartial(PartialUser $partial): User > > In other words, if the definition of User includes a non-nullable property > $name, then any object that doesn't have a value for $name is not actually > a User object. > > Regards, > -- > Rowan Collins > [IMSoP] >
