Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

PHP Town Hall:
Episode 50: Low down on PSR-15
Jun 29, 2016 @ 09:20:22

The PHP Town Hall podcast has posted their latest episode (after a bit of hiatus) giving the low down on PSR-15, the proposed PHP-FIG standard for HTTP middleware.

n all star cast this episode, as Ben and Phil are joined by regular guest Anthony Ferrara - thinker of good ideas and long-time part-time side-line contributor to the PHP-FIG, Woody Gilk - one-speed rider & BDFL of Kohana, and Beau Simensen - author of a bunch of stuff including StackPHP.

Here we’re talking about some awesome stuff the PHP-FIG is working on: PSR-15 (HTTP Middleware). [...] We discuss all this, and the reason PSR-7 (HTTP Message) is not enough for the ecosystem to benefit from shareable middleware. [...] Woody provides a bit of the decision-making process in a very tricky aspect of the FIGs job, which is: should standards be built entirely to match existing implementations, or should standards try to improve on the learnings of the existing implementations to better them all as implementations change to support the standard. It’s all a bit chicken and egg, but a very worthy discussion to have.

You can catch this latest episode either through the in-page video player or directly on YouTube. If you enjoy the show, be sure to subscribe to their feed and get the latest as new shoes are released.

tagged: psr15 phpfig middleware proposal standard phptownhall podcast ep50

Link: https://phptownhall.com/episode-50-low-down-on-psr15/

Anthony Ferrara:
All About Middleware
May 23, 2016 @ 11:06:10

Anthony Ferrara has written up a post for his site sharing more information about middleware and the PSR-7 proposal that's being discussed to help standardize interfaces with this popular form of application processing.

Last week, a proposal to standardize middleware for PSR-7 was introduced to the PHP-FIG. The general concept of middleware is not a new one, and has been in use in the PHP world for many years. Several people have raised significant concerns with the proposal, which have gone completely unheeded by the author. Let me go through the most major of these concerns, as well as show what a better proposal might look like.

He starts off with a brief look at the current proposal - the interface it defines and an example of a real world usage of it to check some attributes on the request/response. He gives a few more examples before getting into what he sees as the fundamental problem with the interface: that it passes in a response instance rather than creating its own ("what does $response mean inside the middleware?"). He's mostly talking about context and not knowing from one middleware to the next what kind of changes may have been made to the response. He also includes some of the arguments on the "for" side of including the parameter and an interesting list of middleware that does this modification prior to the next() call, making it difficult to determine the actual state.

He ends the post with a few other issue he has with the proposal including the use of the __invoke method name, a restriction on typing and the next method being callable. He makes a few suggestions of modifications to the proposal that he thinks could help make it better, correcting these issues.

tagged: middleware psr7 proposal opinion example problem

Link: http://blog.ircmaxell.com/2016/05/all-about-middleware.html

Evert Pot:
Drop 'public' not 'var'!
Mar 28, 2016 @ 12:23:32

In a recent RFC that's been proposed and is now up for voting, the suggestion has been made to drop the var keyword in PHP 7.1 and completely remove it in PHP 8 (made a bit redundant buy the public keyword in classes). Evert Pot, however, disagrees and suggests dropping public instead.

A PHP RFC vote has started to deprecate the var keyword in PHP 7.1 and remove it in PHP 8. At the time of writing, there 23 who say it should be removed, and 18 who say it should not. [...] I’d like to offer a different opinion: I think people should be using var instead of public. I realize that this is as controversial as tabs vs. spaces (as in: it doesn’t really matter but conjures heated discussions), but hear me out!

He goes through an example on one of his own projects, showing how he's mostly removed the public level of exposure from his development (using final and statics instead). He then suggests three common thoughts he sees people having being in favor of dropping var versus public:

  • #1: Everyone doing the same thing is good
  • #2: It’s ugly!
  • #3: The public keyword is useful to convey intent

He also points to one place where he does see the need for a public but also suggests that in that case var would do juts fine too.

tagged: public var class exposure level rfc proposal voting

Link: https://evertpot.com/drop-public-not-var/

Phil Sturgeon:
A Quick Note on PSR Numbering
May 06, 2015 @ 09:41:55

With a lot of talk happening around the PSR-7 HTTP request/response proposal and PSR-4 being the last "official" standard to be posted, some people are wondering what happened to PSR-5 and 6. Phil Sturgeon, a previous member of the PHP-FIG, has posted some clarification to how the PSR process works and where those seemingly missing PSR numbers are at.

The last PSR from the FIG to be sent out into the world, to be used by whoever felt like using it, was PSR-4: Autoloader. Now people are starting to hear about PSR-7, and they’re starting to “lolphp”, wondering what has happened to PSR-5 and PSR-6. [...] This is not like The Neverending Muppet Debate of PHP 6 v PHP 7, despite it being the first though to pop into many peoples heads. Instead, this is down to the Workflow Bylaw I put into place last year.

He goes on to talk about the current workflow stages and how, unlike systems in other languages, the PHP-FIG's process gives proposals a PSR number even before they're published and accepted. He also briefly talks about PSR "nicknames", naming to differentiate between similar proposals and how, despite the need for these names, they're just reference points for conversations more than anything.

tagged: psr7 psr proposal workflow process numbering naming phpfig

Link: https://philsturgeon.uk/php/2015/05/05/psr7-numeric-workflow/

PHP Town Hall:
Episode 36: PSR-7 and the World of Tomorrow
Feb 11, 2015 @ 12:17:34

The PHP Town Hall podcast has release the latest episode today - Episode #36: PSR-7 and the World of Tomorrow. In it hosts Phil Sturgeon and Ben Edmunds are joined by Hari KT and Matthew Weier O'Phinney to discuss the PSR-7 HTTP message proposal currently in the works by the PHP-FIG.

Now PSR chats can be a little boring when its about autoloading or tabs v bloody spaces, but this PSR could have some really big impact on the way you write PHP over the next few years. We talk a bunch about Aura and Zend and their plans around middlewares, what motivated Matthew to get involved with taking over PSR-7, what middlewares mean for PHP in general and some of the concerns that have been fixed in recent iterations of the PSR like mutability, streams, etc. There also a bit of chat about turtles, standing desks and broken ribs, while Phil slowly goes loopy on pain killers.

You can catch this latest episode in a few different ways: either through the in-page audio player, by downloading the mp3 or by watching the live recording over on YouTube. Be sure to subscribe to their feed if you enjoy the episode.

tagged: phptownhall podcast ep36 psr7 phpfig proposal

Link: http://phptownhall.com/blog/2015/02/02/episode-36-psr-7-the-world-of-tomorrow/

Pascal Martin:
In favor of RFC "Scalar Type Hints"
Feb 09, 2015 @ 09:40:18

Pascal Martin has a new post today sharing some of his thoughts around one of the currently proposed PHP RFCs for < href="http://blog.pascal-martin.fr/post/in-favor-of-rfc-scalar-type-hints.html">scalar type hinting. PHP has had type hints for custom objects and some things like arrays but this proposal would add in additional ones for things like "string", "int" and "float".

The Scalar Type Hints RFC for PHP 7 has first been initialized in December 2014. It went on with version 0.2 at the middle of January 2015, after changing several major ideas, and is now in version 0.3, integrating return types, as RFC Return Type Declarations has been accepted a few days ago. [...] I’ve been following this RFC (and the previous ones) with some interest, and, as I’ve taken some time to play with it a bit last week, building PHP from the sources of the corresponding Git branch, I’ll try summarizing here why I think it is interesting. Please note this is my personal opinion.

He starts with a look at what the proposal entails around these new scalar type hints and why he thinks they're a good idea. He looks at some of the things that PHP's current weak typing allows and how it has made the language very flexible as a result. He also shows how the proposal suggests the use of the "declare" function to define a strict typing constant to essentially turn on the checking only where needed. He provides a few code snippet example including object/method handling, setting a custom error handler and which of the calls work in which typing method. He finishes the post looking at the "per-file" idea of enabling the strict typing checks and some of his confusion around the point. He also talks about return types, the directives that are proposed to enable the feature and the current status of the RFC.

tagged: scalar type hint rfc summary proposal php7 opinion overview

Link: http://blog.pascal-martin.fr/post/in-favor-of-rfc-scalar-type-hints.html

Hari KT:
Conduit : The Middleware for PHP
Jan 22, 2015 @ 10:22:16

In his latest post Hari KT looks at Conduit, a middleware system that lets you build PHP applications out of various pieces (the middleware) according to the PSR-7 specification (for HTTP messaging).

Long back, I happened to talk with Beau Simensen about stackphp on #auraphp channel. It was hard for me to digest when I noticed it need symfony/http-kernel and its dependencies. After a few months, I started to like the middleware approach of slim framework and wanted to push it to aura. But nothing happened there. Conduit is a Middleware for PHP built by Matthew Weier O’Phinney lead of Zend framework. Conduit supports the current PSR-7 proposal. I believe like the many PSR’s, PSR-7 will be a revolution in the PHP world. Conduit is really a micro framework and can grow with your project.

Hari walks you through getting the tool installed and includes an example route that just echoes "Hello conduit!"back to the user. With that in place, he shows how to add in some middlewares, chosing the Aura router and dispatcher for more complex route handling, and integrating them into a simple controller/action microframework structure.

tagged: conduit middleware psr7 proposal mwop tutorial auraframework

Link: http://harikt.com/blog/2015/01/21/conduit-middleware-for-php/

Stanislav Malyshev:
Objects as keys
Dec 15, 2014 @ 09:18:50

In his latest post Stanislav Malyshev looks at a RFC he's proposed to allow array keys to be objects including some of his thoughts behind the proposal and how he sees it being helpful to the language.

I’m going to put to vote soon another of my RFCs, namely one about “objects as keys“. So, I want to outline the case for it here and address some criticisms and questions raised while discussing it.

He starts off by answering the "why" question, mentioning specially the introduction of things like GMP numbers and how, despite them seeming to work like numbers, other things can be done with them. He talks about how you'd use this functionality "the right way" and how that'd relate back to value objects. He answers a few other questions about the proposal including why it's better than just using __toString or spl_object_hash instead. He spends the rest of the post looking at some of the implementation problems, disadvantages and some of the possible names (function names) for the handling.

tagged: object array key rfc proposal gmp number

Link: http://php100.wordpress.com/2014/12/14/objects-as-keys/

Pádraic Brady:
Security Oriented PSR Proposed to PHP-FIG
Nov 11, 2014 @ 11:56:42

Pádraic Brady has a new post to his site today talking about a security-oriented PSR that's being proposed to the PHP-FIG group (by Lukas Smith). The proposal suggests the creation of a security policy to be used by members of the PHP-FIG and a way to make sharing security issues more standardized.

Lukas Kahwe Smith recently brought forward an idea to PHP-FIG with two broad objectives for a new PSR: To write a security policy that could be adopted by members; and proposal to make sharing security vulnerabilities more common and standardised. He has invited interested people to express their interest in joining a separate mailing list to discuss the details: https://groups.google.com/forum/#!topic/php-fig/45AIj5bPHJ4. Larry Garfield of Drupal and Korvan Szanto of concrete5 CMS have offered to sponsor the proposal.

He talks some about security policies in general - what they are, why they're a good idea and what Lukas is proposing for PHP projects. He also briefly covers the publishing of vulnerability data, the different options for publishing them and how the standardization of it could be integrated with current tools (Composer anyone)?

tagged: phpfig security standard reporting proposal discussion

Link: http://blog.astrumfutura.com/2014/11/security-oriented-psr-proposed-to-php-fig/

Anthony Ferrara:
What's In A Type
Oct 24, 2014 @ 13:55:39

In a new post to his site Anthony Ferrara takes on the topic of typing in PHP, discussing some of the main ideas around the current typing scheme and the discussions being have about potential changes.

There has been a lot of talk about typing in PHP lately. There are a couple of popular proposals for how to clean up PHP's APIs to be simpler. Most of them involve changing PHP's type system at a very fundamental level. So I thought it would be a good idea to talk about that. What goes into a type?

He starts at the highest level, covering what "typing" is in general and some of the tradeoffs that come with being a strongly typed versus weakly typed language. He then gets into PHP's two "semi-independent type systems" - one for objects and one for everything else. He includes some code examples to illustrate and how, for the non-object handling, context means everything for how the types are switched. He also talks about polymorphism, the chaos that could come from scalars becoming objects and a current RFC suggesting the addition of "safe casting" functions to PHP to provide less "magic" when shifting values from one type to another.

tagged: type switching casting rfc proposal function weak strong

Link: http://blog.ircmaxell.com/2014/10/whats-in-type.html