Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77178
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.200 as permitted sender)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
References: <6893A97A-EC4C-4124-B804-96E2A26B953F@ajf.me> <20140914000718.GB14312@phcomp.co.uk> <3177B936-50C1-4E5D-8687-FD235C72B411@ajf.me> <54153692.7050500@sugarcrm.com>
In-Reply-To: <54153692.7050500@sugarcrm.com>
Message-ID: <9CE963B0-E624-4267-BC2A-0F8D1F985DAE@ajf.me>
Date: Sun, 14 Sep 2014 13:08:03 +0100
Cc: "internals@lists.php.net" <internals@lists.php.net>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Mime-Version: 1.0 (1.0)
Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
From: ajf@ajf.me (Andrea Faulds)


> On 14 Sep 2014, at 07:32, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>=20
> Calling this "scalar type hinting with cast" when it doesn't actually
> cast in wide variety of cases sounds a bit misleading to me. It should
> be called "scalar type checking with restricted casting" or something
> like that.

I'd agree it's not the best name. This is mainly a decision to make when thi=
s is documented or added to the language spec. If we change this thing's nam=
e, we should perhaps stop calling typed parameters 'type hints'.

> I would also ask to clean up an RFC a bit and to clarify which of the
> proposed choices and "possible changes" are actually being voted for
> when somebody votes "yes".

The vote would be for the RFC as it is. Possible changes are things in the R=
FC I was uncertain on. I might hold votes on some of them, actually.

> In any case, I call everybody to vote against this RFC in this form,
> since it introduces inconsistency between internal and user functions
> and makes PHP have two different arbitrary sets of rules for implicit
> conversions, and this can not be good for PHP.

I had abandoned the RFC for this reason. However I gave up trying to improve=
 zpp and make it consistent with user land hints, or adding user land hints w=
hich match zpp.

The problem is that we *can't* be consistent. Internal functions already liv=
e in this completely different world from user land functions. Nullability i=
s handled differently. They use implicit casts in places as if they were use=
r land functions with no parameter types at all. In other places they have s=
trongly typed parameters. If they are passed invalid data, they usually just=
 return NULL and emit a warning, though this depends on the function. User l=
and functions, by contrast, will emit a recoverable error if the wrong type i=
s passed. To make these two consistent would require massive backwards-compa=
tibility breaks.

If we're just talking about casting, then this proposal does not alter casti=
ng behaviour, in fact I've been very careful not to touch it. It does, howev=
er, only accept a subset of the values zpp usually does. This is because it i=
s a compromise between strict and weak parameter typing. While I understand y=
ou might like it to be fully weak like zpp, many userland developers are in f=
avour of something stricter, thus the compromise. Unlike zpp's rules, at lea=
st these rules are clearly specified and prevent data loss.

Thanks!
--
Andrea Faulds
http://ajf.me/=