Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75515
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.115 as permitted sender)
Message-ID: <53C45F62.8060509@sugarcrm.com>
Date: Mon, 14 Jul 2014 15:53:22 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>, Alexey Zakhlestin <indeyets@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <08503591-EFC8-48E6-984E-FFC292C5EA5F@ajf.me> <16D48604-0C0A-4613-91A4-21392E3A2636@ajf.me> <DAE582FE-DABD-42DD-A0C3-ACB5C1BEA6AD@gmail.com> <D00169E9-7F9B-4471-88AA-BED075285B6F@ajf.me>
In-Reply-To: <D00169E9-7F9B-4471-88AA-BED075285B6F@ajf.me>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> That is exactly what is being proposed though. People (including
> Anthony himself, along with other proposals) have previously
> suggested type hints which just casted. However, I don’t think this
> is terribly useful. You can already do that really easily (`$foo =
> (int)$foo;`), and it’s too lenient; the non-scalar type hints are
> useful because they validate your types, and the scalar ones, while
> casting, should validate to a degree.

PHP is weakly typed language, and 100% of existing code is written under
such assumption. If you mean to convert it to strictly typed language,
it won't be PHP. If you mean to make one small piece of it strictly
typed, while the rest is not, it would not give you the advantage of
strict typing (since you still can not prove anything about your code
beyond a very small piece of it) but give you all the disadvantages such
as increased development effort, more boilterplate code, etc.

> Keeping close to zpp would be nice, but zpp’s behaviour isn’t always
> the most sensible and useful one, but we should try to keep somewhat
> close to it.

If zpp behavior is not sensible, we should change it. However, having
consistent conversion rules is much better than have two sets of rules,
each of which make only a little sense, and forcing users to guess by
which set of rules they play each time. We have PHP.next where we can
break things, if some things in ZPP make no sense, we can break them and
fix them and have a good set of rules that does make sense. It is much
better than having two of them.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/