[itry]

Been coding PHP for 14 years. Running several servers with PHP applications. Serving hundreds of thousands of users a month.

None of the issues he wants to get "solved" have ever been an issue to me.

Taking away _GET, _POST and _SERVER would introduce issues.

[kalleboo]

The only item on his list I absolutely agree with is "Unicode everywhere". I don't understand why you'd want to filter the _GET/etc supervars on input, it's on output you need to filter them, depending on where they're going.

The direction I want to see PHP going in is continued improvements in consistency. Stuff like turning all those fatal errors into runtime exceptions. And yes, making all string functions Unicode.

[pilsetnieks]

> why you'd want to filter the _GET/etc supervars on input

I get that the solution he proposed is different, and also reasonably sane, but isn't this basically what magic quotes did? Now that that nightmare is finally over, I'm not too keen on reliving it again.

[jcampbell1]

You really don't want string functions to be unicode. Strings in php are actually byte arrays. If you take that away, you will break far more than you fix. You are basically killing the baby, so substr() works a tiny bit better.

I don't want to have to flag every string as unicode. It is pointless as they already are all unicode, and it is not that bad to know the very small number times where php's binary functions don't work (e.g. substr, regex in certain cases).

[kalleboo]

> Strings in php are actually byte arrays. If you take that away, you will break far more than you fix. You are basically killing the baby, so substr() works a tiny bit better

That's a good point I hadn't thought about - processing binary files. I guess what I really want is a "texual string" class that you can trust. The problem right now are the inconsistent "mb_" functions that you sometimes have to use, don't always exist, and aren't always 1:1 mappings.

[nona]

"Unicode everywhere" is something I hear often, but don't really agree with, unless you mean "Unicode by default and preferred and easy".

The real world still has and probably always will have a lot of text in other encodings - Latin-1, Shift-JIS, heck even things like GSM03.38.

I like how Ruby handles it - every string has an encoding attached, and manipulations with non-compatible encodings will complain.

[rabino]

THIS. Stop trying to fix what's not (completely) broken.

[fein]

Plus, that wrapper already exists with Symfony components.