A Response To "On php-fig and Shared Interfaces"

By | December 20, 2012

(This is a response to Matthew Weier O’Phinney. Full disclosure: MWOP is both my friend and respected peer. Also, like MWOP, I am a voting member of PHP-FIG, and was directly involved in the recent LoggerInterface discussion among that group.)


Matthew wrote:

My primary problem with the idea of shared interfaces is that I feel there is always room for new thinking and ideas in any given problem space, and that this thinking should not be restricted by what already exists.

By definition, truly new thinking is not generally restricted by what already exists. ;-) If lots of developers adopt new thinking on an old problem, I think it is completely within reason to deprecate an older PSR and write a new one that codifies the new approach.

Even so, I always thought a major point of PHP-FIG was to recognize which things we already do much the same way and codify PSRs around them. (I will admit I continue to be frustrated by the unwillingness of other members to do basic research and discovery of this kind.)

Thus, when we consider functionality …

  • that does already exist,
  • that has been implemented by multiple different projects,
  • in ways that are similar despite their varying origins,

… I think it can be very useful to reduce the differences and combine the commonalities into a shared interface.

In the specific case of logging, as Matthew gives, I reviewed each member project’s logging interface or base implementation:

https://groups.google.com/group/php-fig/msg/6e4285dc3116331c?dmode=source&output=gplain&noredirect&pli=1

True, I was examining them in reference to the string-interpolation portion of the proposed LoggerInterface. But I was struck overall by how similar they really were in terms of the basic notification methods. Differences were minor at best. For something like that, a shared interface sounds to me like an unqualified good.


Matthew also wrote:

Secondarily, I feel that it’s okay for a given project to be selective about what capabilities it requires for its internal consumption and consistency, and should not limit itself to a standardized interface.

I completely agree. There’s nothing that says a development effort is required to adopt anything from PHP-FIG. If someone thinks their way is better, then by all means ignore any and/or all PSRs entirely.


To sum up (and MWOP, please correct me if I’m not getting what you’re saying):

One is able to imagine reasons why having shared interfaces of the kind described above is in opposition to, or at best orthogonal to, better development practices and greater innovation across PHP land.

Even so, I assert that shared interfaces as described, while maybe preventing an imaginable ideal in theory, instead promote an actual good in practice.

The actual good can never be as desirable as the imaginable future ideal, but it does have the benefit of being real and present.


UPDATE: MWOP informs me by private communication that I have missed his point. I await his next missive. Here’s his response: http://mwop.net/blog/2012-12-20-on-shared-interfaces.html#comment-744905017

9 thoughts on “A Response To "On php-fig and Shared Interfaces"

  1. Pingback: A Response To “On php-fig and Shared Interfaces” | codegooroo

  2. Matthew Weier O'Phinney

    Just for the public record (since we discussed this via phone earlier)… My challenge to this is that you’re arguing here, with relation to php-fig, the exact opposite of what you’ve argued as differentiating goals for Aura. I’m finding it hard to reconcile both points of view (I see them both, believe you me), and I’m curious to see how you address that contradiction, or if you end up falling on one side of the argument or the other.

    Reply
    1. pmjones Post author

      I too am interested to see what the decision will be. :-) I can think of three options right now, of varying ideological purity. There may be others.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *