4 ms·

I thought something along the lines of keeping the existing global namespace mess but also add in namespaced, consistent aliases like you've suggested, i.e. myS

by cdmckay 12y ago

I thought something along the lines of keeping the existing global namespace mess but also add in namespaced, consistent aliases like you've suggested, i.e. myStr.replace() As the new ones get more use, slowly deprecate and remove the original global namespaced functions, in the same way they phased out register_globals

mreiland 12y ago
right, and then it becomes even less readable because someone calls in the namespace somewhere and half of your project uses 1 version, half the other. No, just stick with the consistency of using the stdlib as is. If someone really has a problem with these specific issues they don't need to be developing, period.
- cdmckay 12y ago
  I would like to think that in any sane project they would choose one of the namespaces and stick with them. Moreover, I think that as you deprecated the older namespaces, this problem would go away. You could make the exact same argument with removing register_globals: half the project using it, while half the project using the superglobals. Clearly there'd be some pain, but I don't think it would be as bad as you're trying to make it sound. I'm not really sure I follow the logic that if someone has an issue with the state of a programming language then they shouldn't be developing. How does that make any sense?
  - mreiland 12y ago
    because you're involved in a strawman. funny how that works.
- bitwalker 12y ago
  It's in the nature of developers to care about API design, which is really what this is about. Would you want someone to design an API for your software product that does so as haphazardly as the PHP standard library was designed? Probably not. It's only natural that people want to discuss why it's bad and how it could be fixed. I would be more concerned if you were a developer and didn't care about these kind of issues.
  - mreiland 12y ago
    if it aint broke, don't fix it, and PHP's stdlib aint broke. It just aint perfect. It will never BE perfect. And that's ok. There's a million things I'd like to see before people start trying to "fix" an stdlib that's been around for so long.
jfoutz 12y ago
or just distribute an upgrader with the next release. I'm sure it's more complicated than just find and replace, but the interpreter has a perfectly good parser right there. eval is impossible (or very hard), but it's pretty legit to error out in that case.
- chriswarbo 12y ago
  It's not legit to error-out for eval, since PHP has all kinds of eval-like things. For example, PHP has two namespaces for functions: anonymous functions live in the regular variable namespace, so they can be passed around directly. Named (AKA global) functions are completely separate, so we can't pass them around as values. For example: $my_anon = function() {}; function my_named() {} // Valid array_map($my_anon, []); // Invalid array_map(my_named, []); As a workaround, whenever PHP sees a string when it's expecting a function, it will try to find a global function with a name matching the contents of the string. In other words, we can do: // Valid array_map('my_named', []); This is basically a weak form of eval: taking a string of PHP code ('my_named') and getting back the value it evaluates to (the my_named function). If you error-out for eval, you have to error-out for this, since the content of strings is runtime information and there's no way you can infer it well enough. For example: function smart_replace() { $args = func_get_args(); $func = array_shift($args)? 'str' : 'preg'; return call_user_func_array("{$func}_replace", $args); } Other eval-like things in PHP include variable property lookups, variable method calls and "variable variables": $foo = "hello"; $object1->$foo = $object2->$foo; // Sets $object1's "hello" property to $object2's $object3->$foo(); // Calls $object3's "hello" method $bar = "foo"; echo $$bar; // Outputs hello One interesting fact about these features is that, since they're not as powerful as a real eval, it can often be perfectly safe to supply them with unvalidated user input: array_map('str_' . $_GET['string_function'], $my_array); There's no way we can swap out things like this reliably, and remember that these are not just "crazy uses of eval", they're officially sanctioned ways of working, which in some cases (eg. function names in strings) have no alternatives (short of redefining your own standard library).
  - aruggirello 12y ago

by cdmckay 12y ago

mreiland 12y ago

right, and then it becomes even less readable because someone calls in the namespace somewhere and half of your project uses 1 version, half the other. No, just stick with the consistency of using the stdlib as is. If someone really has a problem with these specific issues they don't need to be developing, period.

cdmckay 12y ago
I would like to think that in any sane project they would choose one of the namespaces and stick with them. Moreover, I think that as you deprecated the older namespaces, this problem would go away. You could make the exact same argument with removing register_globals: half the project using it, while half the project using the superglobals. Clearly there'd be some pain, but I don't think it would be as bad as you're trying to make it sound. I'm not really sure I follow the logic that if someone has an issue with the state of a programming language then they shouldn't be developing. How does that make any sense?
- mreiland 12y ago
  because you're involved in a strawman. funny how that works.
bitwalker 12y ago
It's in the nature of developers to care about API design, which is really what this is about. Would you want someone to design an API for your software product that does so as haphazardly as the PHP standard library was designed? Probably not. It's only natural that people want to discuss why it's bad and how it could be fixed. I would be more concerned if you were a developer and didn't care about these kind of issues.
- mreiland 12y ago
  if it aint broke, don't fix it, and PHP's stdlib aint broke. It just aint perfect. It will never BE perfect. And that's ok. There's a million things I'd like to see before people start trying to "fix" an stdlib that's been around for so long.

jfoutz 12y ago

or just distribute an upgrader with the next release. I'm sure it's more complicated than just find and replace, but the interpreter has a perfectly good parser right there. eval is impossible (or very hard), but it's pretty legit to error out in that case.

chriswarbo 12y ago
It's not legit to error-out for eval, since PHP has all kinds of eval-like things. For example, PHP has two namespaces for functions: anonymous functions live in the regular variable namespace, so they can be passed around directly. Named (AKA global) functions are completely separate, so we can't pass them around as values. For example: $my_anon = function() {}; function my_named() {} // Valid array_map($my_anon, []); // Invalid array_map(my_named, []); As a workaround, whenever PHP sees a string when it's expecting a function, it will try to find a global function with a name matching the contents of the string. In other words, we can do: // Valid array_map('my_named', []); This is basically a weak form of eval: taking a string of PHP code ('my_named') and getting back the value it evaluates to (the my_named function). If you error-out for eval, you have to error-out for this, since the content of strings is runtime information and there's no way you can infer it well enough. For example: function smart_replace() { $args = func_get_args(); $func = array_shift($args)? 'str' : 'preg'; return call_user_func_array("{$func}_replace", $args); } Other eval-like things in PHP include variable property lookups, variable method calls and "variable variables": $foo = "hello"; $object1->$foo = $object2->$foo; // Sets $object1's "hello" property to $object2's $object3->$foo(); // Calls $object3's "hello" method $bar = "foo"; echo $$bar; // Outputs hello One interesting fact about these features is that, since they're not as powerful as a real eval, it can often be perfectly safe to supply them with unvalidated user input: array_map('str_' . $_GET['string_function'], $my_array); There's no way we can swap out things like this reliably, and remember that these are not just "crazy uses of eval", they're officially sanctioned ways of working, which in some cases (eg. function names in strings) have no alternatives (short of redefining your own standard library).
- aruggirello 12y ago