Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67971
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ralphschindler.com from 209.85.213.43 cause and error)
Message-ID: <51CC6A79.5040306@ralphschindler.com>
Date: Thu, 27 Jun 2013 11:38:17 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: internals@lists.php.net
References: <CAAyV7nGo4+n_4Ad7oKyuvLWTtmnui7fn6s-noCwG2PtT5A70tQ@mail.gmail.com> <51C9FA9C.8050403@sugarcrm.com> <CAAyV7nHz0E2Tmin5_S4OVii=U1HhuKKL6y_KAa+j=X7DT9My6g@mail.gmail.com> <51CA1C93.6080500@sugarcrm.com> <CAAyV7nHo-ZLx2F=+6URctZXTqx8tLgR=xG7j0wJ3unmiCxGvXQ@mail.gmail.com> <51CA24C5.9090505@sugarcrm.com> <CAAyV7nG2Lmo0q01KGbKpBzpJXbs-2E+1ir8yCOFnN8yC-Up2Gw@mail.gmail.com> <51CB167A.4020207@sugarcrm.com> <CAAyV7nHWJYkB0sFWNep=QJqVX7+QsKJ-ne=rD7Qszs98DDx3aA@mail.gmail.com>
In-Reply-To: <CAAyV7nHWJYkB0sFWNep=QJqVX7+QsKJ-ne=rD7Qszs98DDx3aA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RFC: Protocol Type Hinting
From: ralph@ralphschindler.com (Ralph Schindler)

...

> 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