5 ms·

While I understand why this was done (for the sake of comparability), I feel like its better to bite a bullet and slowly phase out broken functions over several

While I understand why this was done (for the sake of comparability), I feel like its better to bite a bullet and slowly phase out broken functions over several versions. Warn initially (few versions) and then raise exception/critical errors after. If developer isn't willing to update, chances are server isnt being updated either anyways.

jtreminio 13y ago
Nothing in this discussion mentions anything broken, though.
- Yver 13y ago
  Indeed, and the title is incorrect too. Function names were not renamed to end up different buckets; Their names were picked that way.
- Someone 13y ago
  What about usability? "I wasn't too worried about not being able to remember the few function names." certainly indicates that usability decreased. That may have set a pattern for it getting broken, eventually.
  - skloubkov 13y ago
    This. I was implying that length of the string should mean length in characters, not bytes. This could lead to broken code and would require programmers to keep in mind both. I have switched from php long ago, but remember odd naming conventions and frequent switch of parameters.
damncabbage 13y ago
Well, not really. Consider the (very common) case of a PHP-based blog, forums or shop being hosted on shared hosting. The latter gets an upgrades, and the site explodes. (I say do it anyway. It's like IE6; give it a long grace period, then tell people they need to get with the program.)
shoyer 13y ago
Better idea: bite the bullet, drop PHP. Switch to a language that was designed. In the eyes of many of us, PHP is beyond redemption.
- skloubkov 13y ago
  Difficult to get as sign-off on re-write of large systems when there technically nothing broken.
- Killswitch 13y ago
  Better idea: Be a better programmer and don't blame a language because you suck.
  - prodigal_erik 13y ago
    No amount of "being a better programmer" can fix the fact that $x == $y && $y == $z does not guarantee that $x == $z or $a[$x] == $a[$y]. Nor that passing by value may or may not protect you from destructive updates, depending on whether your caller passed by reference. The language simply can't be trusted to behave predictably; a huge number of its features have some kind of trap built in by mistake.
    - jl6 13y ago
      Is there actually something non-deterministic about PHP? If not it seems like a better programmer would simply be aware of the language's less elegant features and work around them.
      - awestroke 13y ago
        So, PHP is a good tool because a 'better' programmer can make good things DESPITE using PHP?
        jl6 13y ago
        Who said PHP was a good tool? I'm responding to the parent comment asserting that being a better programmer won't help you, which is clearly not true. All our tools are deficient to a greater or lesser extent, and part of what defines the skill of a programmer is working with the tools you have, working around their deficiencies, and resisting the urge to engage in architecture astronautism. If you have a choice, sure, don't use PHP. But if you don't have a choice, PHP won't stop you shipping a quality product.

jtreminio 13y ago

Nothing in this discussion mentions anything broken, though.

Yver 13y ago
Indeed, and the title is incorrect too. Function names were not renamed to end up different buckets; Their names were picked that way.
Someone 13y ago
What about usability? "I wasn't too worried about not being able to remember the few function names." certainly indicates that usability decreased. That may have set a pattern for it getting broken, eventually.
- skloubkov 13y ago
  This. I was implying that length of the string should mean length in characters, not bytes. This could lead to broken code and would require programmers to keep in mind both. I have switched from php long ago, but remember odd naming conventions and frequent switch of parameters.

damncabbage 13y ago

Well, not really. Consider the (very common) case of a PHP-based blog, forums or shop being hosted on shared hosting. The latter gets an upgrades, and the site explodes. (I say do it anyway. It's like IE6; give it a long grace period, then tell people they need to get with the program.)

shoyer 13y ago

Better idea: bite the bullet, drop PHP. Switch to a language that was designed. In the eyes of many of us, PHP is beyond redemption.

skloubkov 13y ago
Difficult to get as sign-off on re-write of large systems when there technically nothing broken.
Killswitch 13y ago
Better idea: Be a better programmer and don't blame a language because you suck.
- prodigal_erik 13y ago
  No amount of "being a better programmer" can fix the fact that $x == $y && $y == $z does not guarantee that $x == $z or $a[$x] == $a[$y]. Nor that passing by value may or may not protect you from destructive updates, depending on whether your caller passed by reference. The language simply can't be trusted to behave predictably; a huge number of its features have some kind of trap built in by mistake.
  - jl6 13y ago
    Is there actually something non-deterministic about PHP? If not it seems like a better programmer would simply be aware of the language's less elegant features and work around them.
    - awestroke 13y ago
      So, PHP is a good tool because a 'better' programmer can make good things DESPITE using PHP?
      - jl6 13y ago
        Who said PHP was a good tool? I'm responding to the parent comment asserting that being a better programmer won't help you, which is clearly not true. All our tools are deficient to a greater or lesser extent, and part of what defines the skill of a programmer is working with the tools you have, working around their deficiencies, and resisting the urge to engage in architecture astronautism. If you have a choice, sure, don't use PHP. But if you don't have a choice, PHP won't stop you shipping a quality product.