Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78562
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
Message-ID: <545666C3.4080106@gmail.com>
Date: Sun, 02 Nov 2014 17:15:47 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <5455FD7E.1020705@lsces.co.uk>
In-Reply-To: <5455FD7E.1020705@lsces.co.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Personal working styles ...
From: rowan.collins@gmail.com (Rowan Collins)

On 02/11/2014 09:46, Lester Caine wrote:
> The current discussion on http response objects and other aspects of the
> transmission process has brought out a few more 'what the ...' from some
> of you and as with a lot of the 'modern' discussions, the reasons for
> wanting something tend to be wrapped in a lot of assumptions that the
> rest of us understand exactly what is being discussed. In many cases
> I'll be frank - despite starting programming back in the early 1970's
> much of the debate goes over my head!

I think there's a good point here, that we need to make sure - 
particularly in the core of the language - that we maintain PHP's 
long-standing support for writing quick, unstructured programs, without 
a lot of boilerplate.

Ideally, new use-cases which are difficult or awkward with current 
functions would be supported by simply adding new functions in the same 
style as those that already exist. However, PHP's standard library of 
functions is notoriously inconsistent, so the right way to add such new 
functionality isn't always obvious, and sometimes doing so would just 
add to existing confusion or complexity. In such circumstances, it is 
sometimes right that we look at designing a new API which overlaps with 
the old; if this can be done in such a way that the new API is still 
simple for the simple cases, all the better, but if not, the old API 
needs to be maintained as more than just a begrudging compatibility shim.

The superglobals for HTTP requests are probably a good example of this: 
we definitely need to keep them for compatibility reasons, but further 
than that we mustn't start thinking of them as inferior or deprecated if 
their replacement requires an additional 10 lines of boilerplate to be 
added to every 1-page PHP script.

As for PHP-FIG, its mission is rather different - for those people who 
are writing framework-based applications, and modules designed to be 
used by those applications, it is useful to have a set of agreed 
conventions ("Recommendations") to work with. Some of these are 
basically just arbitrary choices, like agreeing whitespace conventions 
so that code shared from one project to another doesn't look out of 
place. Others can be useful even for smaller projects - for instance, if 
you intend to pass around a logger object, you can make it implement 
PSR-3, making it trivial to switch over to a third-party library like 
Monolog if you later decide that would be beneficial.

-- 
Rowan Collins
[IMSoP]