Hi Anthony,

On Wed, Jun 24, 2015 at 12:00 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:

> On Wed, Jun 24, 2015 at 10:40 AM, Anthony Ferrara <ircmax...@gmail.com>
> wrote:
>
>> >
>> > IMHO, escape/unescape/encode/decode/conversion function is better to
>> accept
>> > any types.
>> > HTML template may be separated script, but database code etc may not.
>> >
>> > Writing code like
>> >
>> > <?php
>> > declare(strict_types=1);
>> > $sql = 'SELECT * FROM '. pg_escape_identifier((string)$table). ' WHERE
>> id '.
>> > pg_escpae_literal((string)$id).';';
>> > pg_query($sql);
>> > ?>
>> >
>> > is better to be avoided. i.e. (string) cast before passing parameter.
>>
>> I agree 100%. Instead, the developer should get an error if the
>> parameter is not a string. Because it is an error. If you're passing
>>
> an array to `pg_escape_identifier`, you have FAR WORSE problems.
>> Having the function accept anything and return anything (as you're
>> proposing) would eliminate any ability to detect this problem.
>>
>
> I agree 100%.
>
>
>> If people blind cast, that's their problem. We shouldn't make it
>> harder for people to detect problems by blindly accepting anything
>> under the sun.
>>
>
> strict_types=1 creates issue for int/float which is valid and accepted
> without strict_types.
>
> We will have mixed types due to type hint and it's problematic.
> If escape functions accept string/int/float/object(only when
> it has __toString), it's easier for users. Safety is guaranteed also.
>
> Other than escape/conversion functions that expect "string" type
> should get type errors.
>
>
> > Another example. JSON decode convert numeric to int/float
>> >
>> > <?php
>> > declare(strict_types=1);
>> > $data = json_decode($json);
>> > $str = mb_convert_kana((string) $data['some_data'], 'AKHV');
>> > ?>
>> >
>> > Are we going to enforce users to use (string) casts for conversion
>> functions
>> > to switch
>> > strict_types=1?
>>
>> No, the entire point is to have them actually validate the types.
>
>
> I fully agree.
>
> But people will do this, unless we make conversion functions accept
> safe/valid scalars/objects... Or worse, people make assumption that
> variables are safe to output w/o escape...
>
> Since there weren't contracts before PHP7, I think we may adjust contract
> for some functions before PHP7 release.
>

Another reason of this optimization is type affinity that I would like to
add.

https://wiki.php.net/rfc/introduce-type-affinity

With type affinity, "integer string"/"float string" are converted to
int/float type
and PHP can execute script more efficiently with type hint. i.e. Type
affinity
eliminates countless "string" -> "int/float" conversions with weak type
hint.

Issue with converted values is int/float cannot escape as it is now because
they expect "string" strictly with "strict_types=1", as well as it requires
needless type conversions to "string" in weak mode.
e.g. htmlspecialchars, pg_escape_string/identifier/literal, etc.
Therefore, I would like to allow int/float for these functions.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Reply via email to