Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78982
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Message-ID: <3844e0dd17eef0f8991dd01eda533e2e.squirrel@webmail.klapt.com>
In-Reply-To: <656B2A54-572B-4E6A-892B-25FAE428F434@ajf.me>
References: <66B7B28C-2651-4A71-AC2A-55D4C7BB3DDC@ajf.me>
    <CAGa2bXY4P9dP6rB0-hZ9E5=ALQv+04s157BtwyF7_N3VZV8igA@mail.gmail.com>
    <656B2A54-572B-4E6A-892B-25FAE428F434@ajf.me>
Date: Wed, 19 Nov 2014 09:33:00 +0100
To: "Andrea Faulds" <ajf@ajf.me>
Cc: "Yasuo Ohgaki" <yohgaki@ohgaki.net>,
 "PHP Internals" <internals@lists.php.net>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Safe Casting Functions
From: anatol.php@belski.net ("Anatol Belski")

Hi Andrea,

On Wed, November 19, 2014 04:07, Andrea Faulds wrote:
>

>> On 19 Nov 2014, at 03:02, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>
>>
>> I would like to have DbC to harden app security as well.
>> I'm looking for something like D language.
>>
>>
>> http://dlang.org/contracts.html
>>
>>
>> With DbC, checking parameter types/range/etc happen only when
>> development. Therefore, app runs faster for production.  All of runtime
>> checks cannot be removed from app code by DbC,  so this RFC is nice to
>> have even with DbC.
>
> Something like contracts is actually an idea I’ve had before. Even some
> of the most expressive type systems (like Haskell’s) seem to neglect that
> only a certain range of values of a primitive type may be desired. Having
> something like that in PHP might be useful.
>
> But I wouldn’t say it’s really on-topic.
>
>
> --
> Andrea Faulds
> http://ajf.me/
>
>

while briefly looking through the conversion examples, i see some weird
results

string(5) “31e+7” - shouldn't this be valid for int?
string(4) “0x10” - hex, but that's int, no?
string(3) “010” - octal, but that's int, no?
string(4) “10.0” - this would be casting to 10, so int valid
object(Stringable)#2 (0) {} - and similar actually, what if _toString()
returns some int/float literal? that should pass as well, no?

Generally I'd say no to this RFC. The current casting is not perfect, but
as for me - the one suggested is highly questionable as well. IMO as long
as there are no proper strict types in PHP, any other rule set for casting
would be just another coordinate system for the same, which isn't worth
while at least.

Regards

Anatol