6 ms·

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

by itry 12y ago

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.

rabino 12y ago
THIS. Stop trying to fix what's not (completely) broken.
kalleboo 12y ago
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 12y ago
  > 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.
- nona 12y ago
  "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.
- jcampbell1 12y ago
  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 12y ago
    > 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.
fein 12y ago
Plus, that wrapper already exists with Symfony components.

by itry 12y ago

rabino 12y ago

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

kalleboo 12y ago

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 12y ago
> 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.
nona 12y ago
"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.
jcampbell1 12y ago
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 12y ago
  > 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.

fein 12y ago

Plus, that wrapper already exists with Symfony components.