...
group of people are mostly solved already). The average framework core-dev
(like Symfony or ZF) isn't going to get *much* benefit out of this either
(it can help in some areas, and they will use it, but it's not solving
major problems). The Drupals, Magentos and Fuel CMS's of the world. The
people who make plugins and modules for Frameworks and CMS's.
That's not exactly true. As a core developer of a major framework (zf),
I see a metric *ton* of value in this. Most of the value comes in the
form of how we communicate upstream and downstream dependencies,
requirements, and usage.
Right now, there is a rock and a hard place - and not much else. The
community wants consistent APIs for tools that solve cross cutting
problems (cache, logging, etc). But the only solution is to
collectively, as a community, pick a name, a governing body, and
physical repository. The manifestation of this is the PSR/Fig group.
At current, people who wish to participate have to
a) aid in the decision processs,
b) help craft the code, and host it as part of the 3rd party, then
c) depend (phyically) on the code/interfaces that comes out of a+b
(C) is a tough problem b/c not everyone wants to use a package
management system to pull in these now required 3rd party dependencies,
or alternatively ship them as part of our own code base.
What would be *ideal* is if we can all generally agree on an API and
ship our own interfaces which are structurally equivalent, thus reducing
all external dependencies. This, from a communication standpoint, makes
consumption easier between projects.
Physically,
Zend\Logger\LoggerInterface (zf base log interface)
Symfony\Mvc\LogInterface (sy)
Monolog\LoggerInterface
.. more ..
would all be structurally equivalent through their participation in
FIG/PSR3, and instances of an implementation of any of them could
structually pass for an instance of another.
This is better than what we have now which is having a dependency on
some 3rd party's Logger interface: (PSR\PSR3\LoggerInterface).
So if you don't see the usefulness of this type of change, ask if you
maintain anything significant that fits that description. If you don't,
find someone who does and talk to them. Otherwise you may be unfairly
judging by ignoring problems that you personally don't have...
Here's the important part for people that don't see the use case:
There's no doubt that large groups of developers in the PHP ecosystem
are sharing code more now than I've seen in my 15 years in it. It would
be nice if the engine would facilitate or simplify this kind of
code-sharing in a way that our instanceof/is_a history and roots simply
can't.
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
