Re: [PHP-DEV] default charset confusion

On Wed, Mar 14, 2012 at 3:37 PM, Gustavo Lopes <[email protected]>wrote:

> On Wed, 14 Mar 2012 14:55:17 +0100, jpauli <[email protected]> wrote:
>
> I would then propose to make mbstring compile time mandatory.
>>
>>
> I'm completely against these kind of lazy solutions. Yes, let's add strong
> coupling (already starting to smell) to one of the largest extensions and
> make it compile time mandatory because it simplifies the implementation of
> a dubiously useful feature like Zend multibyte. Remember PHP is sometimes
> used in environments with limited memory/disk space.
>
> Also mbstring takes a long time to build (relatively speaking). Just that
> would be a strong argument against making it mandatory, at least for people
> like me that compile PHP with --disable-all very frequently.
>
>
> I'm against yet another global ini setting, I find the actual ini
>> settings confusing enough to add one more that would moreover reflect
>> mbstring one's (and add more and more confusion).
>> Why not turn ext/mbstring mandatory at compile time, for all future PHP
>> versions, like preg or spl are ?
>>
>> We do need multibyte handling either. ZendEngine takes advantage of
>> mbstring for internal encoding as well, so I probably missed something as
>> why it is still possible to --disable-mbstring (or not add
>> --enable-mbstring) when compiling ? Has it a huge performance impact ?
>>
>>
> mbstring hooks to basically all phases of PHP process/request
> startup/shutdown. Some efforts were made to mitigate the impact of this in
> 5.4 (see e.g. r301068), but at least some impact is inevitable. Of course,
> if you start enabling certain features of mbstring (zend multibyte hooks,
> translation of input variables, function overload) then it starts to be
> significant. However, there are other more compelling reasons not to make
> it required (see above).
>
> --
> Gustavo Lopes
>

That makes sense to me :-)

But we should think about complexity in the final choice.
Having something like "internal_encoding" adding in PHP.ini will confuse
people, at least, if we dont clearly explain them what the setting is for.
The name is nearly the same as mbstring's.

I recently opened a doc bug about multibyte handling in 5.4 (#61373) , as
the documentation is really light on that point

Julien.P

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*?


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi Folks:

This topic appears to have been quietly tabled. I didn't notice a
decision here or a commit.


On Mon, Mar 12, 2012 at 01:12:03PM -0700, Rasmus Lerdorf wrote:
>
> So maybe a way to tackle this is to use the
> mbstring internal encoding when it is set as the htmlspecialchars
> default when it is called without an encoding arg.

This seems like the clearest indicator of the programmer's intent.

Thanks,

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php