Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64605
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50E8DA99.1060604@sugarcrm.com>
References: <CAF+90c_girfbcPBb8rCV3bPNR2Hsd5gyRPB+VArCfqjPPqG5DQ@mail.gmail.com>
	<19D80B01-BE88-4119-8A15-B631A96060E5@mrclay.org>
	<CAF+90c9=HgRLHv4o=5dGkQzZPC5Q0tbPC8GD9AZ13Jwkr0pOcw@mail.gmail.com>
	<CAHjTTqOwrCfprcw3jCiLU21NygYCjrz+3+zpjdnU_sj-JbQonQ@mail.gmail.com>
	<50E8AA4D.5090207@sugarcrm.com>
	<CAAyV7nFW45f5vEUkZXhbgaJe=TL1Tbfp7igbUkQ=ifJc9tAsvQ@mail.gmail.com>
	<50E8C2BA.9080309@sugarcrm.com>
	<CAF+90c9d-1mxdEYGuAXMCkuxxbTSTygvssWgfP3XY6wbLONJxw@mail.gmail.com>
	<50E8CDC8.6080809@sugarcrm.com>
	<CAF+90c8gcDGqzvHRLtHgWkVJgUc8c1z3jv0wjNvFZwtK0quwoA@mail.gmail.com>
	<50E8DA99.1060604@sugarcrm.com>
Date: Sun, 6 Jan 2013 15:48:43 +0100
Message-ID: <CAF+90c9QsjpO9oieVdxeESw60Vxx62tMcfv_dF=fejOWSntUzA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Anthony Ferrara <ircmaxell@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec554df401d228404d29fcfec
Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
From: nikita.ppv@gmail.com (Nikita Popov)

--bcaec554df401d228404d29fcfec
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jan 6, 2013 at 2:59 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> This is pretty bad by itself. But the fact that everybody would be using
> this feature in this way - since they would think "I don't need null
> default, null is always the default and I'd initialize it in the ctor
> anyway", not realizing that declaring "public DateTime $foo" blocks
> unset - is even worse. At least with setter you need to explicitly
> define typehinted setter - and there you have a place to think about it.
> With "public DateTime $foo" 99% of people would never even remember to
> think about it - until they'd start getting mysterious fatal errors on
> unsets. That's why I think it makes it worse.
>

In this mail I'm only going to address the unset() concern.

First of all it should be made clear that contrary to the impression that
you conveyed unset() is a fallible operation. It absolutely is fallible,
even when overloaded properties and offset (__unset/offsetUnset) are not
involved. If I write `unset($foo[0])` then this is an operation that can
throw a fatal error, for example when $foo is a string. Why does this throw
a fatal error? Because a string offset can not be unset. It's an operation
that does not make sense and so PHP throws an error. PHP could also just do
nothing, leave the string intact and pretend the unset() was successful.
But it doesn't do so and it's good that it doesn't do so.

What we are talking about here is a similar situation. We are talking about
a property where it does not make sense to unset it. The unset operation is
not meaningful and as such shouldn't be allowed. It's as easy as that.

That's the first point. The second point is that even *if* an issue existed
here (which it does not) then you are presenting it in a *totally*
disproportional matter. You make it seem like unset()ing properties is this
super important operation that we do all the time and the world would
collapse if it failed. That's not true. Unset() on object properties is
only used *very* rarely. Symfony Standard (including Symfony, Doctrine,
Twig, ...) has a total of !! 4 !! property unsets (compare this to their
~3800 accessor methods). The ZF2 has 8 property unsets of which only !! 3
!! are targeted at specific properties (the remaining 5 are on
stdClass-like objects). Again, compare this to their ~4k accessor methods.

In summary: a) Unset() is a fallible operation, it's okay if it throws an
error if the unset is not reasonably possible. b) Even if you *don't* agree
with this assessment it's quasi a non-issue as property unsets are
incredibly rare. Dismissing a feature based on something like this is
absolutely implausible. c) You can always allow unset() and NULL assignment
by specifying it as the default value. Not hard to do *should* you once run
into issues of this kind.

Thanks,
Nikita

--bcaec554df401d228404d29fcfec--