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]
