Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86832
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZhUPZ2wvtTP_yYuhVUrhkZTFOHh8vx956jW-8aXEY5ag@mail.gmail.com>
References: <CAGa2bXa9x_BK9O78N_yvAVj7M5V0UEGsy3ch-VOimaqGaKUA3w@mail.gmail.com>
	<CABBJUpeaVXXJ-JJDP+oHUamuDGwM87Myvm4_0qXAh2cZn8rg3A@mail.gmail.com>
	<CAAyV7nHo2jWSNYL-BQc-yg2SoTzOpNFvcmLNpH9vhL9w3_ab7w@mail.gmail.com>
	<CAGa2bXYRB1Mo6B9WA0knrJ6ziKukaNY18aiYzj-QfvYA+o0VVQ@mail.gmail.com>
	<CAGa2bXa0c5ducwf075MEZEE1psbn2vVHJCzX8p1KC9JJkyEe=Q@mail.gmail.com>
	<CAGa2bXbPrj89krFpY-N+GoC1fW0gKL7EBXBFP5iLUJAWf3mZ1g@mail.gmail.com>
	<CAAyV7nHX9J8_5X6geOmG9jqCbtxkobsEDBUDEcri0p-TrCRyig@mail.gmail.com>
	<CAGa2bXZhUPZ2wvtTP_yYuhVUrhkZTFOHh8vx956jW-8aXEY5ag@mail.gmail.com>
Date: Tue, 23 Jun 2015 23:05:50 -0400
Message-ID: <CA+sv8zAmE26wtTT4a54UiXJ3UUOVB2Vy4Y8S3pK63JgDD1VoMw@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: PHP Internals <internals@lists.php.net>, Anthony Ferrara <ircmaxell@gmail.com>, 
	Xinchen Hui <laruence@php.net>
Content-Type: multipart/alternative; boundary=089e0158b310becaa205193ac84a
Subject: Re: [PHP-DEV] Optimizing php_html_entities()
From: jrbasso@gmail.com (Juan Basso)

--089e0158b310becaa205193ac84a
Content-Type: text/plain; charset=UTF-8

Yasuo,

Did you test the performance impact on strings? Since you changed how it
works the impact can be positive and maybe worth to make the method more
broad.

Juan Basso
On Jun 23, 2015 23:01, "Yasuo Ohgaki" <yohgaki@ohgaki.net> wrote:

> Hi Anthony,
>
> On Wed, Jun 24, 2015 at 10:40 AM, Anthony Ferrara <ircmaxell@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.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>

--089e0158b310becaa205193ac84a--