Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58946
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.182 as permitted sender)
Message-ID: <4F612C5A.9050600@gmail.com>
Date: Thu, 15 Mar 2012 00:40:10 +0100
User-Agent: Thunderbird
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: Rasmus Lerdorf <rasmus@lerdorf.com>, 
 PHP internals <internals@lists.php.net>
References: <4F5D9C77.3030000@lerdorf.com> <4F5DA152.10109@sugarcrm.com> <4F5DA894.8060606@lerdorf.com> <4F5DAB49.3030808@sugarcrm.com> <4F5DAFCE.8020600@lerdorf.com> <4F5E5148.4030106@sugarcrm.com> <4F5E5219.7080501@lerdorf.com> <4F5E53C3.8060502@sugarcrm.com> <4F5E6A0C.90507@gmail.com> <4F5E6AF4.9090603@sugarcrm.com> <4F5E7F66.6000304@gmail.com> <4F5E85E1.5050202@sugarcrm.com>
In-Reply-To: <4F5E85E1.5050202@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] default charset confusion
From: keisial@gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)

On 13/03/12 00:25, Stas Malyshev wrote:
> Hi!
>
>> Still, that API is likely wrong: a library function written by someone
>> completely unrelated to the main application shouldn't be echoing
>> anything through the output. And if it's not generating the html, the
>> htmlspecialchars is better done from the return at the calling
>> application (probably after converting the internal charset).
>
> Again, you making a huge amount of assumptions about how ALL the
> applications must work, which means you are wrong in 99.(9)% of cases,
> because there's infinitely many applications which don't work exactly
> like yours does, and we have no idea how they work.
No. I'm saying how I consider they should work, saying that an API doing
otherwise is likely* wrong (aka. has a bad design), very much as I'd
consider insane a company policy stating "PHP function arguments shall
be named $a, $b, $c...".
That's obviously my opinion, but I think most applications will conform
to that, just as most apps will use more descriptive argument names than
"$c"**.


* There might be some very very special application where it turns out
to be an appropiate design, but that would be the exception.
** Even though there are 26!/(26-n)! ways to name so badly the arguments
of a n-ary function.


> The main point is that having global state (and yet worse, changeable
> global state) significantly influence how basic functions are working
> is dangerous. It's like keeping everything in globals and instead of
> passing parameters between functions just change some globals and
> expect functions to pick it up.
I agree with you, in the general case. Yet, I consider the html charset
to be a global state. And passing the global variables as parameters on
each function call would be nearly as bad as passing parameters as globals.
I just positioned the opposite way for parse_str(), while being fully
aware of that.


>> Such interfaces may be well served by switching the setting many times.
> That's exactly what I am trying to avoid, and you are just
> illustrating why this proposal is dangerous - because that's exactly
> what is going to happen in the code, instead of passing proper
> arguments to htmlspecialchars people will start changing INI settings
> left and right, and then nobody would know what htmlspecialchars()
> call actually does without tracking all the INI changes along the way.
That's assuming people would need to use different output charsets,
which I don't consider to be the case. How many people is using now the
third htmlspecialchars() parameter?
What makes you think that they would need to change the default global,
*several times per request*?