> 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.
I'd like to see this:
if ($objectVar->property is uninitialized) {
...
}
or/and:
if ($objectVar->property is initialized) {
...
}
--
Erick de Azevedo Lima
Em seg., 20 de mai. de 2024 às 14:28, Larry Garfield <la...@garfieldtech.com>
escreveu:
> 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
>
