How is PHP's namespace implementation inadequate? Use-as statements are the staple of every PHP library that uses namespaces, and this seems like a half-measure to placate less-experienced programmers.
Yes, the worst aspect of PHP is how a lot of library code uses fully-qualified namespaces inline instead of a "use" declaration at the top of the file. I've never understood why.
PHP namespacing in many ways ruined the language. I'm not just talking about the poorly chosen use of the backslash '\' path separator or the fact that namespaces aren't automatically inferred which causes me to have to write "use" endless times at the top of the file which destroys my productivity when working outside an IDE.
I'm talking about the heart of PHP which is stream processing. Why in the world would you destroy the notion of simply including other source files in order to wedge in this C++ centric notion of a namespace? Before "namespace" and "use", the idea was that all of the files included together can be treated as one large file, and sadly that conceptual simplicity has been lost.
Also the lost opportunity of having objects be associative arrays like Javascript, combined with namespacing, have convinced me that perhaps PHP should be forked to a language more in-line with its roots. I haven't tried Hack or PHP7 yet but I am apprehensive that they probably make things worse in their own ways.
I think of PHP as a not-just-write-only version of Perl, lacking the learning curve of Ruby, with far surpassed forgiveness and access to system APIs over Javascript/NodeJS. Which is why it's still my favorite language, even though the curators have been asleep at the wheel at the most basic levels.
possibly. Namespaces are very new to php, so programmers who taught themselves via php might not have much experience using or general knowledge of them
Namespaces in PHP are totally fake, they are not real as it is in C++, where you can actually store data within them.
In PHP the namespace is just a name added to every class construct and nothing else.
This is basically
class MyThing
the same as this
namespace My;
class Thing
However namespaces was a pragmatic design choice that solved the community's problem with code organization and ever increasing project sizes and for that it worked pretty well because introducing namespaces didn't break any existing workflow.
Today though I agree that proper module system would be nicer and now with PHP evolved even further it is perhaps time to introduce them.
Without having deep knowledge about PHP internals it feels like it would be possible to do because you can already today implement your own module system. Here is just something quick & dirty as a proof of concept.
module.php
<?php
return new class {
public const MY_CONST = 47;
private const MY_PRIVATE_CONST = 127;
// with PHP 8.1 you also have readonly properties
public string $myPublic = 'foo';
private int $myPrivate = 17;
public function helloWorld(string $name): void
{
echo "Hello, World {$name}!";
}
};
main.php
<?php
final class ModuleException extends Exception {
}
function module(string $name): object
{
static $modules = [];
if (isset($modules[$name])) {
return $modules[$name];
}
try {
$module = @require $name;
} catch (Error $error) {
throw new ModuleException("No such module {$name}", 0, $error);
}
if (!is_object($module)) {
throw new ModuleException("Module {$name} is not an object");
}
$modules[$name] = $module;
return $module;
}
$my = module('module.php');
$my->helloWorld('Module system');
$other = module('module.php');
assert($my === $other);
The building block in PHP internals is the class - interfaces, traits and enums are all classes in disguise. Could it be possible to use classes for modules as well? Perhaps just add some syntactic sugar on top.
(1) Though I am not familiar with the subject (I avoid OO PHP), you seem to raise a valid point; however one could also consider that the same could probably be achieved with less lines of code, arguably looser coupling, greater re-usability and increased conceptual clarity by not writing that code within an OO model at all.
(2) The namespace argument is a valid one; however; in what percentage of deployment environments is such a concern truly likely to come to the fore? Usually very few, and when combined with non-braindead naming conventions (eg. 'mylibrary_function()') basically never.
Not to mention, if they namespaced all math functions it'd break backward compatibility badly. Given that no core PHP functions are namespaced, I don't see why they should start now.
Also, with the functions in the global namespace you can implement a namespaced copy that takes precedence within the namespace and its children. It can easily confuse people, but I've seen it used to force people away from string functions to their multibyte equivalents (it threw exceptions).
Yeah, I prefer an actual module system over PHP namespaces plus autoloader. It feels like a hacked on module system tbf. BUT I do get lots of real work done using namespaces and a PSR autoloader so it works.
I do wish they would extend auto loading for standalone functions and constants though.
You would prefer PHP[1] where the standard library has no namespaces?
[1] I refer to "classic" PHP. No clue if anything PHP5+ fixed this, though I doubt that they would make such a breaking changed even across major revisions.
You can fake module naming with underscores (ugly but it works) and with duct typing you're only typing the full names of classes sparingly. In Java, the lack of namespaces would drive you insane, in PHP not so much. The lack of namespaces hasn't slowed down the development of very large class hierarchies in PHP -- just look at the Zend framework.
I'm not arguing against namespaces, I'm just saying for PHP they're more of a luxury than a necessity.
>PHP only added namespaces in 5.3.0 and can't modularize their globals into namespaces without causing massive backwards compatibility problems. PHP is stuck with a polluted global namespace
They could do what Python did for 3.0, and make a tool similar to Python's 2to3 that replaces global namespace references.
You love continuing to bring up the Java like example, this discussion however is about PHP. PHP will never have namespacing nested like that in the base language, so no point beating that dead horse.
> why is that bad for language wide utility functions?
There's a handful of reasons, but one important one is backwards compatibility with existing codebases (naming collisions).
Two examples: including loads of functionality into the default namespace instead of developing it as external libraries, and confusing the template language and the programming language which encourages XSS vulnerabilities in PHP written by beginners. When using PHP you normally want to use a different template language to avoid having to audit the code and hunt unescaped output.
The author missed the only valid argument: PHP already has a namespace operator! It is '::' just as it is in C++. Classes are namespaces and PHP should have worked just like in C++ where they stole the design from in the first place.
Instead, because nobody wanted to fix the bunged up internals to make it work properly, they decided to add this new character and make the whole language that much more complicated. Now we have this new operator that we didn't need and a bunch of different syntax and semantics for accessing static class members and namespaces.
reply