Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104248
MIME-Version: 1.0
References: <AM0PR0702MB3684F2B7EFF1826F515BA940E2040@AM0PR0702MB3684.eurprd07.prod.outlook.com>
 <CAF+90c_vvEUYE8_bgPVL0MTJeXik6fYsiueZo644OyZubj74jQ@mail.gmail.com>
 <595b374c-bc4f-9b8a-0013-6485abbfb477@php.net> <CAF+90c8FCMtwRoJEUjBg4XPumzUGFjh0nJa82MFpFFS+WB=rxA@mail.gmail.com>
 <CAG9XoMS2q4uttDpNHPDqSLB78YK1bnS9m7qQE9oTqteGUhTAbA@mail.gmail.com>
 <CALKiJKq9geVL9tLdduPpvGVmT9D8utrQN8oLYy_jqg8hSRhRRw@mail.gmail.com> <41D0A782-E4E2-4B98-9C5D-174143DE9A76@gmail.com>
In-Reply-To: <41D0A782-E4E2-4B98-9C5D-174143DE9A76@gmail.com>
Date: Wed, 6 Feb 2019 16:21:12 +0100
Message-ID: <CAG9XoMQY7J6ykjznuAOv06rKR0mDM-JX-dKYLFOt3EnBv3+X3A@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>, Marco Pivetta <ocramius@gmail.com>, 
	Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000061595805813b4720"
Subject: Re: [PHP-DEV] Re: [RFC] [VOTE] Typed properties v2
From: benjamin.morel@gmail.com (Benjamin Morel)

--00000000000061595805813b4720
Content-Type: text/plain; charset="UTF-8"

>
> Reflection is not slow: it is only slow if you instantiate it continuously.


Even when pre-instantiating the ReflectionProperty objects, it's still 2.5x
slower than a closure-based approach, according to my benchmarks (linked
below), so if possible, I'd like to avoid using Reflection for this sole
reason.

It's possible and someone even worked on an implementation at some point (
> https://github.com/php/php-src/pull/1530), but I don't believe this ever
> proceeded to the RFC stage. (I'm rather doubtful about introducing
> something like this, due to the quite significant increase in conceptual
> language complexity for little benefit. I definitely have no plans to
> pursue such a feature myself.)


Thanks for the pointer! I can see from this thread that another PR has been
merged just over a month ago, to implement a ZEND_ARRAY_KEY_EXISTS opcode
to overcome the performance penalty of array_key_exists():
https://github.com/php/php-src/pull/3360

Couldn't we broaden the scope of this opcode, or add a new one, to support
object properties? Pardon my ignorance, but what is exactly increasing the
language complexity? Do you mean the addition of a language construct to
the parser?

The distinction you need has nothing to do with nulls, it has to do with
> the very specific case of "this property currently violates its contract
> and I want to treat that as something other than an error". I personally
> still think that unset() should raise an error for typed properties, but
> apparently there are cunning hacks that it makes possible; as such, 99% of
> PHP developers should never need to detect this state.


You're right, in most of the cases properties SHOULD be set by the
constructor. I do find the current behaviour interesting, however, from a
data mapper point of view: you might want to retrieve a partial object from
the database, and get an Error if you accidentally access an uninitialized
property, as opposed to the pre-typed properties era, where you would get
null and the "error" would be silenced.

It therefore makes more sense to me to have this as a specific API relating
> to typed properties; if it can be done faster outside the reflection class,
> it could be in the form of a new function like
> property_is_initialized($object, $propertyName); this would be an extension
> of property_exists, that handles the edge case of "declared with a type and
> then explicitly unset".


I don't mind if, instead of another language construct, it is a function;
to avoid the same performance penalty as array_key_exists() however, this
function should have a companion opcode (just like ZEND_ARRAY_KEY_EXISTS).
Would that solve what you call increasing language complexity, Nikita?

Ben

On Wed, 6 Feb 2019 at 15:09, Rowan Collins <rowan.collins@gmail.com> wrote:

> On 6 February 2019 13:46:32 GMT+00:00, Rowan Collins <
> rowan.collins@gmail.com> wrote:
> >it could be in the form of a new function like
> >property_is_initialized($object, $propertyName); this would be an
> >extension
> >of property_exists, that handles the edge case of "declared with a type
> >and
> >then explicitly unset".
>
> PS: I realise that it's also possible to accidentally leave a property in
> this state with a badly written constructor. I am drafting a proposal to
> make this much less likely, and contend that it should not be something
> users should be detecting, other than catching the resulting error.
>
> Regards,
>
> --
> Rowan Collins
> [IMSoP]
>

--00000000000061595805813b4720--