Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83918
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.223.181 as permitted sender)
References: <BAY178-W418C61DF38879BED71640EDE140@phx.gbl>	<3d639901ae85227b219e7ee59b3140fe@mail.gmail.com>
	<CA+kxMuQ52SOWp0dP0okVHrb8wF9U5TUX8OcYpNBP4rEPvdrpFA@mail.gmail.com>
	<CALrkBjYO0SGXBDiSJhxSpnG80S_qerTLL2SX4vi0WygstnM+gw@mail.gmail.com> <CAAyV7nFM9fZYs7b+UiWrmHFcNHwqzRKYFgdeimuNTazZvZx2FA@mail.gmail.com>
In-Reply-To: <CAAyV7nFM9fZYs7b+UiWrmHFcNHwqzRKYFgdeimuNTazZvZx2FA@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQGwbbdURx2shUG2o7Zj2Ywptu8MnAHNhHseASj3TG8CBU/YnAHY8IsNnQx0NDA=
Date: Thu, 26 Feb 2015 21:36:08 +0200
Message-ID: <fe4ee2db32d7096f196019d6492f1d90@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>, Mike Willbanks <pencap@gmail.com>
Cc: Dan Ackroyd <danack@basereality.com>, Theodore Brown <theodorejb@outlook.com>, 
	internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: RE: [PHP-DEV] A different user perspective on scalar type declarations
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
> Sent: Thursday, February 26, 2015 9:29 PM
> To: Mike Willbanks
> Cc: Dan Ackroyd; Zeev Suraski; Theodore Brown; internals@lists.php.net
> Subject: Re: [PHP-DEV] A different user perspective on scalar type
> declarations
>
> Mike,
>
> One point of clarification:
>
> > This is true, however, the types that you are receiving back form a
> > multitude of data sources might be in a mixed format (databases for
> > example often provide representation back as a string, non-json based
> > web
> services
> > provide mainly as a string, etc).   While I know what my data looks like
> > and I know I am always going to get a "string" integer back I do not
> > want to have to type cast this each and every time.  Or that I have a
> boolean
> > integer representation that is in a string... You get the point.   Sure,
> > I
> > could certainly go in and take 5 minutes and cast each one but I'm not
> > certain why the purpose is there... It specifically changes the
> > determination that PHP is a weakly typed language and all of a sudden
> > I now need to care that my string integer boolean is not actually a
> > boolean.
>
> It's funny that you bring up boolean...
>
> With the current coercive proposal, you will still need to worry about the
> types: https://wiki.php.net/rfc/coercive_sth#coercion_rules

That's true, but a lot, lot less.

> Passing boolean(false) where an integer is expected will generate an
> error.
> This is a common practice, specifically around internal functions.
> Example:
> https://github.com/sebastianbergmann/phpunit/blob/a4e23a10d4eeea5fd9f
> e8916859a07430b94cf42/src/Util/ErrorHandler.php#L58

It's actually not nearly as common as one might think, and arguably - it's
may be hiding bug or at least some misunderstanding about the semantics of
the argument (not always, but sometimes).  Warning about it (as deprecated)
makes perfect sense.  I'm going to send some data from real world apps later
today or early tomorrow.  Spoiler - not a lot of breakage at all, and
coercive rules seem to have a remarkably good signal to noise ratio.

> The difference is with the dual-mode RFC you can choose not to have to
> cast
> and keep everything as-is today (or more specifically, you need to
> explicitly
> choose strict mode). And you can have user-land behave identically to
> internals **in both cases**.

Put another way, coercive gets to keep a single, sensible conversion
rule-set in PHP - with relatively minor updates needed over the course of
several years.  And contrary to what might be implied here, it would require
a LOT less casting - while still taking advantage of much better data
sanitation.

Zeev