Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64590
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50E8CDC8.6080809@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>
Date: Sun, 6 Jan 2013 02:39:22 +0100
Message-ID: <CAF+90c8gcDGqzvHRLtHgWkVJgUc8c1z3jv0wjNvFZwtK0quwoA@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=f46d0401f8e1373e4d04d294c8e1
Subject: Re: [PHP-DEV] [RFC] Alternative typehinting syntax for accessors
From: nikita.ppv@gmail.com (Nikita Popov)

--f46d0401f8e1373e4d04d294c8e1
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Jan 6, 2013 at 2:05 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:
> You convinced me that this feature is actually harmful to PHP - dealing
> with unset() throwing fatal errors is much worse than occasional empty()
> check. This is a huge landmine - now any code that unsets object
> property can return fatal error, and there's, unlike is_null, not even
> any way to check it.

Wait, what are you talking about here? About this particular proposal or
the accessors RFC in general? The fact that unset() can throw a (catchable)
fatal error is just the same without this particular syntax. If you define
a property with an object-typehinted set accessor, then unset() will not be
possible (throwing a catchable fatal). And I really don't see what's wrong
with this. Unset() does not and should not work silently on anything you
pass it. Some things just can't be unset() and we shouldn't pretend like
they can just by silently ignoring. On this topic, a tangentially related
note: The current accessors RFC will make an unset() call on a property
without setter just do nothing *without an error*. I don't know why you
would think this is a good idea. I honestly can't see how just silently
ignoring instructions is any good. If something can't be unset PHP should
tell you so, rather than leaving you with an (incorrect!) sense of the
operation being performed successfully.

>> The timeframe in which it is NULL is usually contained to the
constructor.

> So what? Objects are constructed all the time, and constructors can call
> any other code. Also, nothing really guarantees the constructor actually
> has initialized the variable - the constructor author could have
> forgotten it just as you could have forgotten to initialize it without
> "no NULL" requirement - so when you are using the API of the object, you
> can not know if the constructor initialized it or not. And if you're
> sure your code is right - you don't need null checks anyway, as you know
> your code never assigns null there.

There are some things one should address here:

1. First of all, there never is a guarantee for everything. All kinds of
typing mechanism can only go so far. They are supposed to help you find
mistakes and prevent issues, but they can't do *everything*. If you know
some magic method to prevent all possible bugs in software, please let me
know. Typehinting is just another defense mechanism preventing many common
faults, but it can't prevent everything.

2. Secondly, the main purpose of typehints is to prevent people setting
incorrect values. If you know that only a "DateTime" instance is valid and
that NULL is not valid, then you should allow only that, only the DateTime.
Allowing NULL absolutely doesn't make sense (as it's not a valid value for
your application), so I'm not sure why you insist on allowing it.
unset()ing it doesn't make sense, so we shouldn't allow it. Your
argumentation goes along the lines of "It's possible that this property
could maybe end up being NULL, so it does not make sense to prevent people
from assigning NULL". The second part of that sentence does not follow from
the first part. The fact that it can be NULL before initialization does not
mean that we shouldn't prevent API users from doing a NULL assignment.

3. The constructor is typically (or at least that's how it *should be*)
small and doesn't do work, so there isn't much to do wrong. But sure, it
can still happen that you forget to initialize something, no arguing that.
The typehint on the property will not prevent this, absolutely. Still it
will prevent all other incorrect assignments to the property, which is
exactly its goal.

I'd summarize this as follows: The typehint prevents all incorrectly-typed
assignments, but it does not prevent missing initialization. Your
argumentation is that because it can't prevent missing initialization, we
shouldn't bother with preventing incorrect assignments either. I hope you
realize that this makes no sense.

Nikita

--f46d0401f8e1373e4d04d294c8e1--