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)` ?

Reply via email to