On 20-5-2024 19:41, Erick de Azevedo Lima wrote:
> 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 <mailto: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 <mailto: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
If we're talking syntax and introducing new keywords anyway, why not go
with a new language construct like `is_initialized($obj->property)` ?