Re: Optimizing php_html_entities()

Hi Anthony, On Wed, Jun 24, 2015 at 12:00 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > 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. > 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 yohgaki@ohgaki.net