
A Crash-Course in PHP Namespaces for WordPress Developers - eamann
https://stevegrunwell.com/blog/php-namespaces-wordpress/
======
firefoxd
The WordPress ecosystem is the one place we need this the most. Adding a plug-
in to your wp instance is always a gamble because you know it's gonna break
something else.

Kudos to the author for helping solve a real problem.

~~~
jstewartmobile
Namespaces are more like a mitigation than a solution.

The problem is tight-coupling. Until that is addressed, plugins will always be
little fail-bombs.

~~~
debacle
It depends on the plugin. Some of these methods are just helper functions for
template rendering. Loose coupling isn't going to contribute a ton there, but
not polluting the global namespace is important regardless of coupling.

~~~
jstewartmobile
Write enough code, and you will know that " _just_ " is a famous last word.

An actor model approach where one failure doesn't compromise the entire chain
would help, but that is _hard_.

------
debacle
The fact that WordPress and other large projects still support PHP 5.* is one
of the major things holding PHP back. Supporting PHP 5.* in 2018 is like
supporting IE8 in 2018.

~~~
toast0
WordPress and other large, popular projects got where they were by meeting
their users where the users already are.

If I have to convince my webhost to install PHP 7 or I can't run your
software, I'm not going to run your software. If I have to convince my webhost
to install PHP 7 or I can't upgrade your software, I'm going to run the shitty
old version until it gets hacked into a distribution site and the bandwidth
use gets high enough for me to notice and turn the whole site off.

I'm not familiar enough with PHP these days to know, but if upgrading to PHP 7
is going to break the shitty old version, that's a problem too. (I think PHP
has tended to be pretty good about not breaking things on upgrades though)

~~~
smacktoward
_> if upgrading to PHP 7 is going to break the shitty old version, that's a
problem too_

The problem is that PHP 7 finally removed some legacy APIs that had already
been deprecated for an eternity. The removal wasn't a bad decision in and of
itself, but there's a non-trivial amount of code in the wild that still uses
those ancient APIs, either because it was written more than a decade ago
before they were deprecated, or because it was written by people who either
didn't understand what "deprecated" means or didn't care. So when that code
moves from 5 to 7, it breaks.

WordPress core is developed by smart people who stay on top of changes in the
language they work in, so moving to 7 wasn't a problem for WP itself. It _was_
a problem for lots of WP themes and plugins, however, since there's lots of
those that were written and then abandoned before 7 was a thing, and even some
that were written by people who knew 7 was coming and just didn't understand
why they should care.

If I were going to suggest one thing WordPress itself could do/have done to
make the transition less rocky, it would be to require PHP 7 compatibility for
plugins and themes distributed through the official repositories at
wordpress.org. Currently that's not a requirement -- there's not even a way to
filter out PHP 7 compatible plugins and themes from the ones that are stuck on
5. So unsophisticated users are still getting recommended software by those
repositories that _will break_ if you run it in a modern PHP environment.

(You can avoid this problem somewhat by looking for other heuristics that
correlate well with PHP 7 compatibility -- actively updated plugins will tend
to be compatible, well-reviewed plugins will tend to be compatible, etc. But
you can't just ask directly for plugins that will work with PHP 7, which is a
shame.)

------
aussieguy123
Look at the drupal source code on github, its all namespaced. The over a
decade old wordpress core codebase is still old procedural style PHP.

------
esaym
How is this news? Been doing this in perl since 1995.

------
chryton
Hey Steve.

------
jakeasmith
Hi, Steve.

