Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81849
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54D2B3FA.6020900@gmail.com>
References: <CA+9eiLuueVvYgT-fhCvzBSxzoDioinpc5Eok5OQtGDBG1FZM=w@mail.gmail.com>
	<CAGa2bXbQsh4qWizf+1k15+BvdNGqjD8OCPGx7S=WAhCPqimXuA@mail.gmail.com>
	<CA+9eiLsnyoxPO7b3oQEN5RbqVE0K6o-01FQR7SYfZQD=QLka5Q@mail.gmail.com>
	<00c101d04049$ca411ec0$5ec35c40$@tekwire.net>
	<CA+9eiLtfpnBH4H_uyM5yZe8M2C_70XKgy3aJ7P6VwdOk0psnQQ@mail.gmail.com>
	<54D1CA7C.8060204@php.net>
	<CA+9eiLupaFmejNfSKMyGTF=iOrMJfttpdwknpTGadwTgv4zb1w@mail.gmail.com>
	<54D1E6EC.7060702@php.net>
	<54D2B3FA.6020900@gmail.com>
Date: Thu, 5 Feb 2015 02:37:09 +0200
Message-ID: <CAPhkiZxj_T5KQJEQZbj30XKs=6NHOXk9hp5=+WVvQz2hFQPPKQ@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Sebastian Bergmann <sebastian@php.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] What do we need strict scalar type hints for?
From: narf@devilix.net (Andrey Andreev)

Hi,

On Thu, Feb 5, 2015 at 2:06 AM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
> Hi!
>
>>  We are talking about adding support for scalars (string, integer, ...)
>>  to the list of optional type declarations already supported (array,
>>  callable, interface name, class name) by PHP. When a developer chooses
>>  to use a scalar type in the signature of a function or method then it
>>  should be enforced as strictly as the already supported types. It should
>>  be up the caller to perform explicit type casting when required.
>
> That is contrary to the nature of PHP as it has been a weakly typed
> language for 20 years. I think it would be a big mistake to change one
> of the basic concepts of the language, that has worked pretty well
> judging from it adoption.

Adding another concept, not changing the existing ones. And really,
it's just simplifying what is already present via is_<typename>()
runtime checks, making our lives a little bit easier.

Though, I should re-iterate - I'm not in favor of picking just one of
the two possibilities.

> Especially given that all internal functions
> do not and will not work this way. Unless you propose make internal
> functions work this way too, in which case it'd be much better to change
> the name of the project, because there won't be much left that connects
> it to prior PHP and you can pretty much forget about BC.

Cheers,
Andrey.