FutureProgrammingTechnologyWeb Development

and now for something completely different

In the our 20-odd years with PHP, there have always been people attempting to work a step or two ahead of where the language was at the time. Working with PHP4 in the early 2000s, when a very elementary Java-derived object model was grafted on the language, people attempted to write proper Java without the guardrails. Objects are the sort of thing that, if your language doesn’t give you, you will probably try to invent, as people before that with PHP3.

PHP5 brought the gradual strengthening of the language’s object model, as well as dynamic “magic methods” which people ran wild with in the late 2000s, stretching things every which way. By the early 2010s the ecosystem had sobered up and begun to build serious structures around it. The language got a proper package manager in Composer, and in playing by a set of community-established conventions, one could draw upon vast resources for free. Many of us did, and over the lifespan of PHP5, the language completed a transformation from its hobbyist origins to something more enterprise-worthy. This was only aided by the widespread shift to cloud-centric computing, which PHP — stateless by nature — was uniquely equipped to handle.

PHP: The Next Generation

PHP7 came at an opportune time in the mid-2010s. Apparent competition from Facebook’s PHP-based hacklang seemed to kick the release schedule for PHP5’s sequel into high gear, amidst worries that a competing, partially-compatible offshoot would fragment the ecosystem. The internals team, which typically ties major version jumps (3 to 4, 4 to 5, 5 to . . . 7) to significant engine improvements, did not disappoint. Version 7 arrived with huge speed improvements (5x, by many counts) and set about, over the lifespan of the 7.x line, finishing the task of strengthening the language’s guardrails. The end result took much of the wind out of hacklang’s sails and, though it continues as a part of facebook’s internal toolset, the feared splintering of the community did not arrive.

Now, as we await the arrival of PHP Next Generation — Version 8 — in the closing months of 2020, let’s look at how we’ve continued to work at the margins in our time with PHP 7, and how we can expect to see our visions realized in future PHP.

make it so

Building a more reflective environment

Beyond the speed boost, PHP greatly strengthened the type system, once considered a critical weakness of the language. Once a weakly typed language, its modern incarnations are more accurately gradually typed — that is to say, while you can still work in a fast and loose way as before, structure and boundary may be introduced as the lines become more defined.

Through external tools, through linters and validation, structure and boundary may be enforced on a project level. The language may be wielded in a way acceptable to the enterprise, without losing the dynamism, flexibility and lightness of weight that characterize a scripting language.

If PHP is the best of both worlds, it’s the hardening of its type system that has brought it there, and it’s around its type system that our work has revolved.

class Before {
protected $database;
public function getUser($id, $password);
}
class After {
protected $database;
public function getUser(int $id, string $age): User;
}

Before is an example of a method signature, PHP5-style. We can infer that $id is probably a number, and $password is probably a string of text. getUser probably returns a user record. These are all reasonable assumptions, but there’s no actual indication of this, and certainly no enforcement. What happens if you pass in a textual ID and a numeric password, or trick it to return something other than a user record? And putting aside everything that could go wrong at runtime, there’s little usable information here for an IDE to provide hinting as you work.

(In the months before PHP7 was announced, our team had a working model that looked an awful lot like After, running entirely on plain-vanilla PHP 5.4. We stopped work on it at that point, and the less we say about how we did it, the better.)

After, using the syntactic enhancements of PHP7, is replete with useful information for automated tools and human readers, and establishes clear boundaries for runtime operation. Try feeding in the wrong values, or coaxing out a bad result. The engine itself will refuse.

So what did people do before 2015? Labour with blind IDEs, unable to analyze their code? No, the PHP community did what it does in the face of adversity and established sensible community standards. Deriving from the Javadoc format, DocBlocks became a standard way of expressing the intent of a program.

class Annotated {
/** @var Connection */
protected $database;
/**
* Retrieve a user from the database.
* @param int $id
* @param string $password
* @throws UserNotFoundException
* @returns User
*/
public function getUser($id, $password);
}

In this way, people were pretending that PHP was well-typed long before it was. Now, these specifications are suggestions, not rules: the language does not register them and will not enforce them at runtime. But they provide a standard way to provide a wealth of metadata beyond what the type system can adequately capture, even now. (Referring back to the After diagram, you’ll notice that this diagram contains more information. PHP 7.0 was incapable of attaching type information to $database, and it doesn’t specify possible error states.)

So on our side we’ve got a consistently improving type system and well-defined documentation format with broad community support. We’ve got powerful Reflection capabilities built in to the language — that is, programs can read their own blueprint, make decisions based on their own structure. All this within a language with a history of dynamism and “magic” undefined conditions.
So let’s look at one way in which we worked past a shortcoming of PHP, and had the opportunity to loop back once the language caught up.

Typed Properties in PHP 7

Let’s dwell for a second or two on a fragment of the last two code samples, to see a shortcoming of PHP 7.0 as it initially shipped.

class After {
protected $database;
}
class Annotated {
/** @var Connection */
protected $database;
}

In contrast to methods, class properties such as the $database are as weakly-typed as ever before. Within a class, it’s the honour system. If you were to make $database public rather than protected, you’d be merely trusting the rest of your system not to pass in a bad value, and you’re telling the rest of system nothing (except by way of commentary) of its intended content.

Meanwhile, our team is building a framework around a Dependency Injection container, and this is a crucial bit of missing information for us as we attempt to analyze and fulfill the needs of a class.
But since we have metadata available in another way, we end up with something like this:

class ExampleController {
/**
* @var UserEntity
* @Inject(required=true)
*/
protected $user;
}

No, not the prettiest. We earnestly wished, at the time, that we could express property types like this:

class ExampleController {
protected UserEntity $user;
}

and Annotations like this, such as in Java:

class ExampleController {
@Inject(required=true)
protected $user;
}

but we continue to build our system as if the language had those functionalities, without our own implementations as a stopgap. In each case, we were expecting the language to go that way eventually, though we couldn’t say for certain any timeframe.

Sure enough, as development of PHP 7.x continued and initial shortcomings were resolved one by one, we got one item checked off our wishlist with PHP 7.4. Typed Properties now allowed the above to be slimmed down to:

class ExampleController {
/** @Inject(required=true) */
protected UserEntity $user;
}

Furthermore, the properly typed property doesn’t function just as a suggestion for the dependency system to interpret and fulfill. Another guardrail, formally in place, and we began supporting this method within our framework immediately. But its addition didn’t invalidate the old method. @var annotations remain valid and will remain so indefinitely.
But speaking of annotations…

Annotations in PHP 8

This is a bit of a “stop the presses” moment, as I had already written how this remains a long-running, major item on our wishlist. How I had followed various RFCs over the past decade, hopeful for each of them, resigned to the reality that it might never be accepted.

Our half-way implementation might be all we ever had, and that was okay. Then, with my press date looming, this lands in my inbox:

i just closed the vote. [Attributes v2](https://wiki.php.net/rfc/attributes_v2) was accepted with 51 yay, 1 nay. The selected syntax will be <<Attribute>>.

Thank you everyone for participating in the discussion and vote!

I was more than glad to tear up that draft, and I’ll be glad to see DocBlock annotations become an optional feature as code like this becomes the norm:

class ExampleController {
<<Inject>>
protected UserEntity $user;
}

Yet, even as the language has caught up with our intentions and we’ve adapted our course accordingly, functionality has remained consistent throughout. The language gave us enough rope to mock-up both features to the degree that we didn’t feel impoverished in their absence, and were able to pivot effortlessly when both were introduced.

It remains to be seen what aspect of PHP 9 we end up building, but we look forward to discovery.

There are many reasons to be excited for PHP 8!

Annotations — er, Attributes — are a definite favourite here, but a major PHP release is a big deal and we’ll be here in future weeks to go through them all.

MarketingProgrammingSEOSocial MediaTechnologyWeb Development

Panda Rose

Panda Rose Consulting Studios Inc is expanding and we have opened a second office in St. Albert

Panda Rose has recently celebrated 10 years in business and have also decided to expand! Our new office in St. Albert is located at 13 Mission Ave, right off downtown! We can be found downstairs in suite 1140. Come by and say Hi!

Panda Rose St Albert

We have been member of the St. Albert Chamber for a while, always with the intention of expanding into St. Albert and are continuing to support the local Chamber and it’s businesses by being members and even sponsoring the next Business Luncheon on June 12th!

Join us June 12th for the Kick Off To Summer Business @ Lunch by grabbing your tickets HERE

Location:
840 St. Albert Trail #105
St. Albert, AB
Date/Time Information:
11:30 am – Reception
11:45 am – Commencement of Meeting and Lunch
1:30 pm – Scheduled End Time
Fees/Admission:
Members $40
Non-Members $50

 

ProductivityProgrammingTechnologyWeb Development

Recent years have seen the proliferation of high-quality package management tools for a wide range of web development languages. Ruby’s gems were always a key selling point of that platform, allowing for a sort legendary developer productivity which is now, thankfully, widely available regardless of platform.


But dependency management is an art unto itself, one that many give little thought to until something breaks catastrophically, leaving developers scrambling to patch some obscure dependent module they didn’t even know they had, as the left-pad debacle did for Node.js developers earlier this year.

If, as developers discovered that day, your project is only as strong as your weakest dependency, it’s prudent to have a handle on what you’re pulling in, from whom, and how you’re doing it.


Big names like Facebook were caught off-guard as everyone else, and the desire to be in control of their dependencies has doubtlessly led to the creation of yarn, a new JavaScript package manager, which we, too, are very excited about.

Operating alongside npm, meant as a drop-in replacement, Facebook touts the following benefits:

  1. Speed
  2. Reliability
  3. Security

The latter two benefits are tied to a .lock file, something that PHP users of Composer are likely familiar with, but which npm lacks:

The magic clue behind it? Whenever you run yarn install, the yarn.lockfile has precedence over the package.json.

If the yarn.lock file exists, the (exact) versions defined in it will be used.

If no yarn.lock exists, the (loosely defined) versions defined inpackage.json will be used, and a yarn.lock is generated.


Dependency Management for PHP

Package management on the PHP side seems comparatively safe and manageable. PHP has an extensive standard library, and we’re unlikely to pull in 100 packages to boot a simple application. It’s much easier to survey the landscape of an application’s dependencies and get a feel for what’s there and why it’s there.

Features that yarn aims to bring to the table for JavaScript developers, such as that lock file, have always been part of our workflow. So, perhaps you haven’t thought about it too deeply.

In fact, you might have questions which are worth reviewing.

Why the composer.lock file matters

How precisely does it relate to composer.json? Should I commit it to version control? How do I manage conflicts?

Managing PHP Dependencies Properly

What should I pull in as a dependency, and what as a dev dependency? Should I need to modify a dependency, what’s the correct way to go about it? How do I optimize my package usage for production?


Above all, be mindful of what you pull in, what that which you pull in pulls in, and the faculties your toolchain offers to allow you to manage these, lest today’s convenience lands you in an uncomfortable situation down the line.

YEG PHP 2.0

A place for Edmonton-area PHP developers to meet and collaborate. Administered by www.pandarose.ca

ProductivityProgrammingTechnologyWeb Development

PHP, one of many languages Panda Rose has experts for.

A very common question that goes by my desk is “What programming language does your team specialize in?” I always find that question amusing for a variety of reasons, the biggest being that while I understand the adage “A Jack of all trades is a master of none.” I also appreciate the fact that if I am hiring a law firm, I do not just hire one person within that law firm. Nor, I hope, do I hire a large law firm where everyone who works for it is only familiar with one statute of the field of law.

Would you hire a patent law firm, if all they knew was the patent law specifically around inventions made in the 1990s?

Would you hire a real estate law firm, if all they knew was property law in the Montreal area?

Yes, there are very specific circumstances where that would be useful, but many would hire them as specialists to aid your usual lawyer, and not as the go-to for everything law.

So why would you hire a software development firm who only knows how to install WordPress, and install a few plugins, a theme, and ensure that the whole house of cards does not collapse until after you pay their contract?

They may save you money in the short-term, but the long-term costs could be massive, in some cases far more than you had originally budgeted.

As I have considered this over the years, I came the conclusion that a software consultancy should not follow the “Jack of all trades” adage as a firm. Yes, we have specialists who know the deep intricacies of the programming languages they work in, but we have more than one of them, and they do not all overlap on a single language. This way, we provide the service that best fits you.

So to answer that question, “Which programming language do you specialize in?” We specialize in the language that will help you succeed.

We are your dedicated CTO.

356 views
ProgrammingWeb Development

An Earth-shaking release like PHP 7.0 is tough to follow-up, and at first glance, the upcoming PHP 7.1 release appears, shall we say, not as exciting as the last. But don’t let that damper your enthusiasm, for the PHP 7 line is indicative of a language reaching a state of maturity and stability, and what we have with 7.1 is a cautious incremental release that moves things forward at a pace befitting this.

Indeed, #internals is full of exciting RFCs mapping future courses that we’d love to tinker with today, but are not decidedly not ready for prime-time. As much as we like new toys, we spend enough time staring down large PHP codebases that we’re excited by many of the incremental improvements found in 7.1.

Let’s run through those areas of improvement that have caught our eye.

Return Types

The addition of Return Types in 7.0 has gone a long way toward solidifying our APIs, moving vital interface parameters out of documentation and into the code, where the parser can enforce what was previously a suggestion. 7.1 brings two subtle but useful refinements of this system.

Void Return Types allow you to specify a function that is expected to return literally nothing, whereas before you would omit the return type and specify void in the documentation block accompanying the function.

Nullable Types allow for returns that are either a specified type or a null, much as you might specify

ObjectType $variable = null

upon input, allowing either that type or nothing at all. This is one that we’re looking forward to in particular, allowing for more flexibility in the construction of cohesive interfaces.

Array Unpacking

Having worked extensively with ES6 and having become very used to its destructuring syntax, this is an area of welcome improvement.

First is a more concise notation, optionally replacing the use of the list keyword, bringing things more in line with the square-bracket array syntax we’ve enjoyed since 5.4.

Second, the allowance of keys within the list construct allow properties to be extracted by name, much as we’ve come to expect on the JavaScript side.

Iterable Pseudo-Type

PHP has long had the Traversable interface, allowing iterable objects to be treated relatively interchangeably and foreachd without regard to specifics, much as you’d treat an array. Except array itself is not an object, and could not be interchanged with a Traversable. You could specify an iterable object or an array, but not both at once.

7.1 resolves this with Iterable, nicely encompassing array primitives and iterable objects under a single umbrella. It’s a small change that brings considerable flexibility to your API.

Closures from Callables

Over the past couple years, our framework has come to be increasingly driven by callbacks, while avoiding some of the common pitfalls through sensible class-based organization (patterns our ES6 and PHP7 codebases have increasingly come to share.)

However, JavaScript objects are wide open and lack a concept of private or protected members. Previously, class-bound callables we wished to pass around had to be marked public in our PHP codebase, even when it would be appropriate to limit and allow the parent class to dispense access.

This could be accomplished with hacky workarounds that we’d rather not use in production, but now we have a language construct to do so in a safe way.

… and more!

Head over to php.net for an exhaustive list, and tell us what you’re looking forward to in the comments.

Finally, remember that the PHP development process is a remarkably open and democratic one, and that you too can get involved and help shape the language’s future.

355 views
ProductivityProgrammingWeb Development

In many ways, the transition to PHP 7, from the 5.x line we had used for many years before, was a clean break, an opportunity to clean house and sweep aside development practices and software dependencies that had outlived their usefulness.

 

Operating on a codebase which had grown out of the days and practices of CodeIgniter and their ilk, which had proved useful for years but was unquestionably showing its age, we jumped at the opportunity to build the framework we would like to use in 2016, rather than the one we had inherited from 2009.

Here was an excuse to revamp our development practices, throw out bits that made sense in 2008 but were a source of a headache today, and incorporate improvements that have taken hold in the ecosystem in the meantime.

Most notable improvements are the standardization efforts that have occurred under the umbrella of PHP-FIG, and the package management ecosystem(courtesy of Composer) that these standards have enabled and allowed to thrive.

A packaging system is something that, given a lack of, you will inevitably try to invent yourself — poorly, incompatibly, and inevitably counter-productively. Such was the state of the PHP framework ecosystem before standardization, and the reorientation of our own framework from an inward-facing framework to an outward-looking one. A framework which naturally integrates with third-party packages and is itself incorporated into third-party packages in a similar fashion.

In this series, we will explore the changes that have occurred in our own development practice, the ways in which these are reflective of the ecosystem as a whole, and why these make for such an exciting time to be writing PHP on the backend.

Stay tuned.

388 views