On Sat, May 18, 2024, at 5:41 PM, Rowan Tommins [IMSoP] wrote: > On 18 May 2024 17:13:49 BST, Larry Garfield <la...@garfieldtech.com> wrote: >>However, that breaks down with readonly properties, which are not allowed to >>have a sentinel. Uninitialized is their sentinel, for better or worse. > > Sorry, I don't understand this statement at all. A readonly property > can be set to PatchState::KeepCurrentValue just like any other. If the > intention is that that state will be overwritten with an actual value > later, then it's not a readonly property. > > I guess you have some different scenario in mind? > > >> And as I noted earlier in the thread, when writing a serializer or other >> dynamic systems (an ORM probably would have the same issue), you really need >> to be able to differentiate between null and uninitialized. Even if you >> think the uninitialized value is a sign of an error, it's coming from code >> you don't control so you have to be able to handle it somehow. > > If a property is uninitialized, the object is in an invalid state, and > attempting to read that property gives an error. That's by design, and > as it should be. > > Are you saying that you want to be able to detect the error before it > happens? Why?
For context, remember I maintain a serializer library, so I have to support objects that may indeed be in an invalid state, and depending on the incoming data may not be able to guarantee an object is in a valid state. I have to do everything via reflection and/or visibility-busting closures. I also maintain an attributes library that, necessarily, has multiple methods that get called post-constructor before the object is "ready." Admittedly neither of these are common cases, but neither are they invalid cases. Readonly's current design, and the (IMO, very bad) support from SA tools, works on the assumption that your readonly properties are 1. Based on constructor params; 2. are always guaranteed set after the constructor. While those are true in the majority case, they're not true in the universal case. IOW, "this readonly property is not set by the time the constructor is done, so your object is invalid, so your argument is invalid" is not a fair or accurate statement. And even then, lots of code needs to be able to inspect an object to determine if it is valid or not, even if just to give the user a better error message than "Oops, you tried to read an uninitialized property, we gonna crash now." (As noted, I maintain multiple such libraries. ORMs would be the other big use case, I think.) All of which is to say that, yes, there are use cases for an "is this property initialized" check that is less fugly than the get_object_vars() hack I have to rely on now. --Larry Garfield
