Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123375
Subject: Re: [PHP-DEV] [DISCUSSION] Checking uninitialized class properties
To: internals@lists.php.net
References: <CAAX=eQNH0xyoRkMDThvG_aNS5Hub3tFD52v4PY3OZKT_zWaMmg@mail.gmail.com>
 <CAPzBOBN1M3H-ueqUtzfb_HPv2jZeDaYVTvXideVnx9QYG6LKeA@mail.gmail.com>
 <CAAX=eQPiRs0sq5z2xdtfV9bnf0waV6O+QaAUEfcM90Pwf3+M=g@mail.gmail.com>
 <878c09ca-860e-4c0c-85ae-2cd0246cda3c@rwec.co.uk>
 <5014b401-6341-44c6-a16e-f453ab52220c@app.fastmail.com>
 <47E8FDF4-9805-4A0B-A2E1-55CF8721253E@rwec.co.uk>
 <133158d0-1371-4b7c-a2f4-242bfe99ce10@app.fastmail.com>
 <CAGS0MVDgDoU1TVdhjvxfDhcEymFtt0d0qtb67Bw8b5RtXGsO4w@mail.gmail.com>
Message-ID: <664BDE7C.8080509@adviesenzo.nl>
Date: Tue, 21 May 2024 01:36:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CAGS0MVDgDoU1TVdhjvxfDhcEymFtt0d0qtb67Bw8b5RtXGsO4w@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------080000000703010201030907"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------080000000703010201030907
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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 
> <larry@garfieldtech.com <mailto:larry@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
>     <larry@garfieldtech.com <mailto:larry@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)` ?


--------------080000000703010201030907
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 20-5-2024 19:41, Erick de Azevedo
      Lima wrote:<br>
    </div>
    <blockquote
cite="mid:CAGS0MVDgDoU1TVdhjvxfDhcEymFtt0d0qtb67Bw8b5RtXGsO4w@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>&gt; 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.  <br>
        </div>
        <div><br>
        </div>
        <div>I'd like to see this:</div>
        <div><br>
        </div>
        <div>if ($objectVar-&gt;property is uninitialized) {</div>
        <div>...<br>
        </div>
        <div>}</div>
        <div><br>
        </div>
        <div>or/and:<br>
          <br>
          <div>if ($objectVar-&gt;property is initialized) {</div>
          <div>...<br>
          </div>
          <div>}</div>
        </div>
        <div><br>
        </div>
        <div>--</div>
        <div>Erick de Azevedo Lima<br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">Em seg., 20 de mai. de 2024 às
          14:28, Larry Garfield &lt;<a moz-do-not-send="true"
            href="mailto:larry@garfieldtech.com" target="_blank">larry@garfieldtech.com</a>&gt;
          escreveu:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
          Sat, May 18, 2024, at 5:41 PM, Rowan Tommins [IMSoP] wrote:<br>
          &gt; On 18 May 2024 17:13:49 BST, Larry Garfield &lt;<a
            moz-do-not-send="true" href="mailto:larry@garfieldtech.com"
            target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:larry@garfieldtech.com">larry@garfieldtech.com</a></a>&gt; wrote:<br>
          &gt;&gt;However, that breaks down with readonly properties,
          which are not allowed to have a sentinel.  Uninitialized is
          their sentinel, for better or worse.<br>
          &gt;<br>
          &gt; Sorry, I don't understand this statement at all. A
          readonly property <br>
          &gt; can be set to PatchState::KeepCurrentValue just like any
          other. If the <br>
          &gt; intention is that that state will be overwritten with an
          actual value <br>
          &gt; later, then it's not a readonly property. <br>
          &gt;<br>
          &gt; I guess you have some different scenario in mind?<br>
          &gt;<br>
          &gt;<br>
          &gt;&gt; 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.<br>
          &gt;<br>
          &gt; If a property is uninitialized, the object is in an
          invalid state, and <br>
          &gt; attempting to read that property gives an error. That's
          by design, and <br>
          &gt; as it should be.<br>
          &gt;<br>
          &gt; Are you saying that you want to be able to detect the
          error before it <br>
          &gt; happens? Why?<br>
          <br>
          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.<br>
          <br>
          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.<br>
          <br>
          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.)<br>
          <br>
          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.  <br>
          <br>
          --Larry Garfield<br>
        </blockquote>
      </div>
    </blockquote>
    <br>
    <br>
    If we're talking syntax and introducing new keywords anyway, why not
    go with a new language construct like
    `is_initialized($obj-&gt;property)` ?<br>
    <br>
  </body>
</html>

--------------080000000703010201030907--