[wp-hackers] Facebook API and WordPress Plugin Development - Insight / Best Practice

[Otto]

On Wed, Nov 14, 2012 at 5:22 PM, Mike Schinkel <mike at newclarity.net> wrote:
> Has anyone else recognized this as a problem?  Is there an easy solution I am just missing?

No, there is no easy solution. Nor do I think the problem is a
universally soluable one, since what you're describing isn't specific
to WordPress, or to PHP, or anything else in particular. Essentially,
the problem of library versioning is a commonplace one to many
systems.

In Unix/Linux, they "solved" it by basically making libraries either
dynamically loaded, or statically loaded. Thus, for any given binary,
it can opt to use the latest version on the system (which is centrally
managed), or it can opt to be compiled in a static manner, where it
contains its own copy of any particular library. If there's a breaking
change to a library and a binary uses it in a dynamic way, then the
binary will generally simply crash, depending on the severity of the
change. Libraries that tend to change a lot thus tend to get compiled
in a static fashion more often. It's a very decentralized solution to
the problem, developers will make the decision on their own, but users
can compile too and recompile if stuff starts breaking. Linux people
tend to be DIY-ers a lot, so it works for them.

PHP could solve the problem of having to rename libraries with the
idea of namespaces, but this is really just the same solution in
different clothing. You're loading your own copy of the library into
your namespace so that you can be sure what your code is doing.

Your "traffic cop" idea basically requires a centrally managed set of
libraries. Which is sort of the idea behind PEAR, except that PEAR is
very generic to PHP in general, and doesn't usually tend to be
particularly concerned with backwards compatibility with older PHP
versions. And you're right, the traffic cop approach doesn't work
unless it's very central to the community in general. Aka, core
supported.

The way I tend to solve it is to avoid using libraries at all,
whenever possible. If I need to use Mark's library, then I wouldn't be
using it in a situation where there was the possibility of conflict
(custom one-off plugin or theme, not something I'd release to the
public), or I'd take out the core functionality I needed from it and
integrated the code directly into my own code instead. This often lets
me optimize for my specific use-case in the process, which is nice,
but it does mean a bit more work, usually, in understanding how the
code works.

Again, I don't think the problem is capable of solution. As long as
you use libraries, you will have library conflicts. The more common
the library, the more conflicts you'll have, unless the library is
*very* stable.

-Otto