4 ms·

PHP has deprecated obviously insecure behaviors that are largely Web-related, yes. I'm coming from a Perl perspective, where deprecating bad language features

by eevee 13y ago

PHP has deprecated obviously insecure behaviors that are largely Web-related, yes. I'm coming from a Perl perspective, where deprecating bad language features means things like "radically overhauling how variables work" or "putting major community effort into eliminating an entire kind of variable". I'm not aware of many similarly-radical changes in PHP, except perhaps whatever happened with PHP 4's short-lived classes.

stephenr 13y ago
Radically overhaul how variables work? Im not sure i even understand what that is supposed to achieve? Make them not variable any more? You're suggesting self-proclaimed radical changes but not giving any information about the actual advantages?
- eevee 13y ago
  Ah, sorry, some actual context might be helpful. In Perl, variable declaration was originally even worse than it is in PHP: any variable, anywhere, required no declaration and was assumed to be a global. (This was inherited from... some combination of awk and shell, I guess.) Obvious problems aside, a practical implication was that recursion was pretty awkward, since the callee and the caller were sharing the same namespace for the same code. Perl 5.000 introduced the `my` function, which would declare a variable as lexically scoped. This solved the practical issues, but it left the problem of error-checking: a typo in a variable name would still create an implicit global with no warning. The solution was the opt-in `use strict;` declaration, which disabled the implicit-global behavior and made unrecognized variable names a compile-time error. Code could be fixed and then opt into the stricter semantics on a per-file (or even per-block!) basis, and nowadays most Perl devs will jump on you like a pack of hyenas if your code doesn't start with `use strict;` or some equivalent. Over time other features with too-sharp edges have been culled, still supported by the interpreter (Perl is more or less compatible going back decades) but made illegal in strict mode. JavaScript's weird "use strict" opt-in is a spiritual port of Perl's approach, stuffed into a string literal to fit into the existing syntax. One of its effects is even the same: assigning to an unrecognized name is now illegal, rather than creating an implicit global. I'm not aware of anything so fundamental being changed in such a heavy-handed way in PHP. From the outside looking in, I'm not even sure the PHP community has a strong consensus on what PHP-specific features to avoid. I'd be happy to learn that I'm wrong on either count.
- stephenr 13y ago
  thanks for the info - it makes sense now. its a similar issue to non-declared vars in js as you mentioned, but even then that was not a language fault per-se, it's just a lack of knowledge about the language. i can't think of things that actually come up like that in php these days - things like register globals and magic quotes are long gone..
  - eevee 13y ago
    I disagree that it wasn't a language fault; it provided very little benefit and directly caused hard-to-diagnose bugs. Being told where the mines are doesn't make walking across a minefield any more palatable. If it were a good idea it wouldn't still be around. Undeclared variables in PHP produce an E_NOTICE, right? Better than Perl 4, at least. :)
  - stephenr 13y ago
    yes reading from undeclared php variables causes an error, assuming you haven't silenced using @ or set php to ignore notices.

by eevee 13y ago

stephenr 13y ago

Radically overhaul how variables work? Im not sure i even understand what that is supposed to achieve? Make them not variable any more? You're suggesting self-proclaimed radical changes but not giving any information about the actual advantages?

eevee 13y ago
Ah, sorry, some actual context might be helpful. In Perl, variable declaration was originally even worse than it is in PHP: any variable, anywhere, required no declaration and was assumed to be a global. (This was inherited from... some combination of awk and shell, I guess.) Obvious problems aside, a practical implication was that recursion was pretty awkward, since the callee and the caller were sharing the same namespace for the same code. Perl 5.000 introduced the `my` function, which would declare a variable as lexically scoped. This solved the practical issues, but it left the problem of error-checking: a typo in a variable name would still create an implicit global with no warning. The solution was the opt-in `use strict;` declaration, which disabled the implicit-global behavior and made unrecognized variable names a compile-time error. Code could be fixed and then opt into the stricter semantics on a per-file (or even per-block!) basis, and nowadays most Perl devs will jump on you like a pack of hyenas if your code doesn't start with `use strict;` or some equivalent. Over time other features with too-sharp edges have been culled, still supported by the interpreter (Perl is more or less compatible going back decades) but made illegal in strict mode. JavaScript's weird "use strict" opt-in is a spiritual port of Perl's approach, stuffed into a string literal to fit into the existing syntax. One of its effects is even the same: assigning to an unrecognized name is now illegal, rather than creating an implicit global. I'm not aware of anything so fundamental being changed in such a heavy-handed way in PHP. From the outside looking in, I'm not even sure the PHP community has a strong consensus on what PHP-specific features to avoid. I'd be happy to learn that I'm wrong on either count.
stephenr 13y ago
thanks for the info - it makes sense now. its a similar issue to non-declared vars in js as you mentioned, but even then that was not a language fault per-se, it's just a lack of knowledge about the language. i can't think of things that actually come up like that in php these days - things like register globals and magic quotes are long gone..
- eevee 13y ago
  I disagree that it wasn't a language fault; it provided very little benefit and directly caused hard-to-diagnose bugs. Being told where the mines are doesn't make walking across a minefield any more palatable. If it were a good idea it wouldn't still be around. Undeclared variables in PHP produce an E_NOTICE, right? Better than Perl 4, at least. :)
- stephenr 13y ago
  yes reading from undeclared php variables causes an error, assuming you haven't silenced using @ or set php to ignore notices.