Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117487
MIME-Version: 1.0
References: <624d81b4.1c69fb81.eae57.b277SMTPIN_ADDED_MISSING@mx.google.com>
 <CAPzBOBMAUGHKkN1gFVYPUiMbNGz7Ni+u7tdS+EB2M-axugVvzg@mail.gmail.com> <CAC5V6ggKqX0pCDjD3BKsuj78bBNEV_CvegZnoZ-uLCSiYCn67Q@mail.gmail.com>
In-Reply-To: <CAC5V6ggKqX0pCDjD3BKsuj78bBNEV_CvegZnoZ-uLCSiYCn67Q@mail.gmail.com>
Date: Wed, 6 Apr 2022 18:27:30 +0100
Message-ID: <CALKiJKq9hXgJn8dmQmanq3f8fQQSJFx7u5w=m3E2gzoD0aL4mQ@mail.gmail.com>
To: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bfe7f305dbffad78"
Subject: Re: [PHP-DEV] [RFC] Undefined Property Error Promotion
From: rowan.collins@gmail.com (Rowan Tommins)

--000000000000bfe7f305dbffad78
Content-Type: text/plain; charset="UTF-8"

On Wed, 6 Apr 2022 at 14:37, Guilliam Xavier <guilliam.xavier@gmail.com>
wrote:

> First sentence of the introduction: "Undefined properties are those that
> have not yet been defined either by the presence of a property declaration,
> or by adding them to the properties hashmap through direct assignment, or
> by having them assigned by an internal function such as json_decode."
> `$obj->prop` alone doesn't define the property "prop", but `$obj->prop =
> whatever` does.
>


I missed the implications of this at first too; maybe some examples would
be useful?

The more I think about it, the more different scenarios there are here,
some of which are more obvious than others:

1) Reading a property that is not listed in a class definition, and has
never been written to
2) Reading a property that is not listed in a class definition, but HAS
previously been assigned to
3) Reading a property that IS listed in the class definition, but has been
"removed" with unset()
4) Reading a property that is listed in the class definition, but has no
default value, and has never been assigned

For each of these, we could consider the behaviour:

a) on an instance of stdClass
b) on a class with the AllowDynamicProperties attribute
c) on a class with neither

Of these:

* Case 1 seems like the most obviously in scope of the proposal.
* Case 2c would be impossible, because assigning to the property would
already have given an error. 2a and 2b are the open question that's already
been mentioned.
* Cases 3 and 4 already throw an error for *typed* properties, which track
the special "uninitialised" state, but for untyped properties case 4 does
not currently raise a Warning.


As with the previous RFC, I think this should be an opportunity to define
the consistent behaviour we want, rather than just looking at what previous
versions did.

Regards,
-- 
Rowan Tommins
[IMSoP]

--000000000000bfe7f305dbffad78--