On Thu, Jun 27, 2013 at 6:38 PM, Ralph Schindler <ra...@ralphschindler.com> wrote: > ... > > >> 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 >
Hi, Could you give some real scenarios for this since you are in such a position and you also see this metric ton of goodness? I think they would help understanding the benefits much better and would also help clear the waters a but. Can you come up with some bad scenarios for this as well? Best regards ---- Florin Patan https://github.com/dlsniper http://www.linkedin.com/in/florinpatan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
