Freek Van der Herten has posted about a new package that's essentially a stand-alone version of Laravel's own "macros" functionality available via a package: macroable.

We recently released our newest package called macroable. It contains a trait that, when applied to class, can dynamically add methods to that class. This trait is basically a stand alone version of the macroable trait in Laravel. In this post I’d like to show you how you can use it, how it works behind the scenes and explain why we created it.

He then gives examples of how it can be used to add a new simple method (essentially a "named closure") and using the "mixin" functionality to add multiple at once. He wraps up the post with a look at how it works behind the scenes, adding the items to a "macros" list and then looking them up if they're not defined on the class.

On the Tighten.co blog there's a recent post showing off some of the magic of Laravel macros and how they can make extending the basic framework functionality simpler.

Ever wanted a piece of functionality in a part of Laravel that doesn’t exist? Let me introduce you to Laravel macros. Macros allow you to add on custom functionality to internal Laravel components.

He gives an example of adding a simple "introduce" macro on the Request facade and how to put it to use. He refactors this into something more useful: returning a true/false result when checking the TLD on the current domain. He includes the code to set up the macro in the AppServiceProvider and the addition of an enhancement that adds a "where" clause to a model query when the TLD matches. He wraps up the post giving some guidance on where they should be defined and what components in the Laravel framework are "macroable".

Fabien Potencier is back with a new post on his site following up this article about application composition and Symfony 4. In his latest post he compares two approaches to applications: micro versus macro.

Monolith projects versus micro-applications; a never-ending debate. Both ways to develop applications are fine in my book. Symfony supports both. Even if the Symfony Standard Edition is probably more suitable for monolith projects as it depends on the symfony/symfony package.

[...] Silex took another approach where each individual components are required when needed. Does it make Silex simpler, more lightweight, or faster than Symfony? No. Nevertheless, Symfony 4 is going to be more similar to Silex in this regard.

He talks about changes upcoming in Symfony 4 including the move away from the "symfony/symfony" package system and in with a component/bundle driven system. He gets into a specific example around the "symfony-framework" bundle. He then comes back around to the idea of "composition" of applications, adding Symfony dependencies only when needed but still having them work together seamlessly. The post ends with a discussion that was had about going the "bundle-less application" route and, while Symfony 4 will recommend it, the bundle system will still function as expected.

There is one trait in the source code that pulls my attention. I’m talking about the Macroable trait. In case you don’t know, you can define custom responses using macros.

He includes an example of extending the default Response class with a "caps" macro and how it would then be used in the resulting object. He talks about how traits work in PHP OOP code and how they can be used to "inherit" functionality into a class. The "macroable" trait then uses the __call magic method to do its thing, looking for macros that match the function being called.

The SitePoint PHP blog has posted another tutorial from author Christopher Pitt sharing another one of his "interesting things" you can do with PHP. In this latest articleChristopher returns to the idea of "macros" to help with some pre-processing in PHP applications and, ultimately, creating a new language feature without some of the usual overhead.

Aware of how painfully slow it can be for an outsider to suggest and implement a new language feature, I took to my editor…

He starts with a brief refresher on macros to do some pre-processing on PHP scripts and allow you to make custom language features that then get interpreted into valid PHP (often with some interesting eval tricks involved). He starts by building a "base" to add in the C# style getters and setters in a special format inside of a class. He includes the macro definitions to set this up and the result once it is passed through the "yay" precompiler. To get around having to run that precompiler every time manually, he creates a custom autoloader to do the job dynamically. He then takes this logic and packages it up so it can be easily installed as a Composer dependency. With this structure in place, he moves on to the creation of a new language feature - the actual functionality for the getter/setters. He ends the post with a screen capture showing the language feature in use and some of the interesting things you can do with it.

Freek Van der Herten has a post to his site with a guide about debugging collections in Laravel applications. He quickly shows how to use the "macro" functionality to gather more insight into what's happening inside.

Lately I’ve been working a lot with collections in Laravel. If you’re not in the know: a collection is a sort of super charged array with a lot of powerful functions to transform the data inside it. The only thing I found a bit of a hassle is how to debug the various steps in a collection chain. Here’s how I improved the workflow.

He shows a simple collection setup with a chain of functions being applied to transform the data inside (ex: filter, map, sortBy). He was able to get a bit more information by using the dd helper Laravel provides but it's not the most "clean" way to just wrap the collection on it. Instead he proposes he use of a "macro" to call the dd function and keep it in the flow of the methods called on the collection (as ->dd()).

The SitePoint PHP blog has a new tutorial posted from author Christopher Pitt continuing on his look at macros in PHP (part one is here). In this new tutorial he gets beyond the basic example he provided in part one and recreate some expressive syntax from Javascript and prefixing strings.

I was so excited about my previous article about PHP macros, that I thought it would be fun for us to explore the intersection of macros and functional programming. PHP is already full of functions, with object oriented patterns emerging relatively late in its life. Still, PHP’s functions can be cumbersome, especially when combined with variable scope rules…

[...] It’s not significantly more code [to append the prefix in PHP vs Javascript], but it isn’t as clear or idiomatic as the JavaScript alternative. I often miss JavaScript’s expressive, functional syntax, when I’m building PHP things. I want to try and win back some of that expressive syntax!

He starts with a quick install of the yay library used in the first part of the series. Instead of the manual prefixing from his first example, he creates a macro that uses the array_map handling to generate the necessary code once the pre-compiler has done its job. He then expands on this simpler solution and updates it to allow for the setting of the prefix string. It gets a little complex but he walks through each step of the way, explaining the code that's added and what it expands out to. The result is a map method that generates a bit of code that's eval-ed to handle the prefixing automatically.

On the SitePoint PHP blog they've posted another tutorial from Christopher Pitt, this time about macros in PHP, and how you can use the Yay library to add in custom pre-processed macros to your code.

I get really excited when developers feel empowered to create new tools, and even new languages with which to solve their problems. You see, many developers come to PHP from other languages. And many PHP developers can code in more than one language. Often there are things in those languages — small syntax sugars — that we appreciate and even miss when we’re building PHP things.

Adding these to a language, at a compiler level, is hard (or is it?). That is unless you built the compiler and/or know how they work. We’re not going to do anything that technical, but we’re still going to be empowered.

He starts off by describing the goal: a simple "range" macro that creates an array and fills it with integers. He helps you get the library installed and shows how to use it to pre-process a file and output the PHP version. He shows how to create the syntax for the macro in the format Yay is expecting for the array_slice shortcut. He also includes handling letting you slice out a portion of an array using the same notation. Finally he shows the resulting code after the pre-processing has happened and the macros have been resolved.

In a new post to his site Igor Wiedler looks forward and suggests some alternate syntax for PHP based around the idea of macros from Lisp. These macros would be parsed at runtime and handled directly as code, compiled down from their custom format.

A very common problem that many software projects have is lack of adoption of new versions. Browsers are an excellent example of this, But it exists on the server as well. [...] This leads to this recursive problem of hosting companies not upgrading because they don't have to, and software not requiring newer versions of their programming language, because they don't want to lose their users. The longer your dependency chain is, the more you suffer from this.

He points out that the easier it is to update these lower level pieces, the simpler it is to introduce new things into your system. He suggest that macro-like functionality for PHP could aid in this goal. He talks some about backporting features and how these marcos could make it easier to upgrade just the things we wanted (or all of them) without having to upgrade PHP itself. He even went so far as to create a tool (galapagos) that does this kind of parsing. His examples implement the 5.4 features of short arrays, $this in closures, function array dereferencing and callable typehinting.

Being able to invent your own syntax is very useful, which instantly becomes apparent when you look at the past. Features get added to languages all the time. What if you could do that easily, within minutes instead of months?

Without going into theoretical details, some of which are quite alien to me, I'll try to describe some of the challenges that pattern patching rewriting macros might pose for a language like php. After brief explanation what kind of a beast is this, I try to explore some of the finer points, which might cause problems. The intent of this post is to sketch a design and highlight some of the possible issues.