Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83919
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nFM9fZYs7b+UiWrmHFcNHwqzRKYFgdeimuNTazZvZx2FA@mail.gmail.com>
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>
Date: Thu, 26 Feb 2015 13:45:38 -0600
Message-ID: <CALrkBjZ9A1p-24FuJCqRV6sDNWL6XJFLSQYLZtD6qCR9V-82AQ@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Dan Ackroyd <danack@basereality.com>, Zeev Suraski <zeev@zend.com>, 
	Theodore Brown <theodorejb@outlook.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01182faa0f6cc4051002ffa3
Subject: Re: [PHP-DEV] A different user perspective on scalar type declarations
From: pencap@gmail.com (Mike Willbanks)

--089e01182faa0f6cc4051002ffa3
Content-Type: text/plain; charset=UTF-8

Anthony,

On Thu, Feb 26, 2015 at 1:29 PM, Anthony Ferrara <ircmaxell@gmail.com>
wrote:

> 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


For some unbeknown reason I was inside of my head going ok, i have a string
integer so that would make an integer and then it would make a boolean.
Thank you for pointing out my obvious miss there :)


>
>
> 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/a4e23a10d4eeea5fd9fe8916859a07430b94cf42/src/Util/ErrorHandler.php#L58
>
> So yes, you'll still need to go in and cast each one **in both RFCs**
> (or handle the errors properly).
>

This is certainly a common case, actually quite often for database purposes
do we need to handle booleans to integer conversions which my integer comes
back as a string (depending on which extension of course) and which type
field it is.


>
> 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**.
>
> Anthony
>

Mike

--089e01182faa0f6cc4051002ffa3--