Array Column Laravel Package

Getting Started

ramsey/array_column is a tiny compatibility shim: it defines a global array_column() function for projects running PHP < 5.5, where the function does not exist natively. It is archived and frozen (last release March 2015), so treat it as a maintenance dependency, not a feature to build on.

Minimal setup:

composer require ramsey/array_column

There is nothing to configure or register. The package declares an autoloaded file in composer.json ("files": ["src/array_column.php"]), so requiring the Composer autoloader is all that is needed:

require __DIR__ . '/vendor/autoload.php';

$records = [
    ['id' => 1, 'name' => 'Ada'],
    ['id' => 2, 'name' => 'Grace'],
];

$names = array_column($records, 'name'); // ['Ada', 'Grace']

Where to look first:

• src/array_column.php — the entire implementation; it is guarded by if (!function_exists('array_column')), so it is a no-op on PHP 5.5+.
• composer.json — confirm the files autoload entry and the php requirement.
• README.md / CHANGELOG.md — historically documents supported PHP versions and the exact polyfill semantics.

First use case: a legacy PHP 5.3/5.4 application (or a library that must support them) that wants array_column() for extracting a single field from a result set—typically mapping database rows to IDs or names without a manual foreach.

Implementation Patterns

Drop-in usage, no wrapper required. The polyfill exposes the native signature, so application code stays portable between old and new PHP. Do not import a class or call a static method; just call array_column().

Composer-driven activation. Because the file is loaded via autoload.files, the function becomes available as soon as vendor/autoload.php is required—before any framework bootstrap. This makes it suitable for use inside other libraries' code paths that cannot assume PHP 5.5.

Common data-shaping patterns in legacy code:

// Extract IDs from query results
$ids = array_column($rows, 'id');

// Re-index rows by primary key
$byId = array_column($rows, null, 'id');

// Group-friendly mapping (pre-5.5 lacks array_column's 3rd-arg alternative
// in some older shims, so verify behavior in the file you ship)
$namesById = array_column($rows, 'name', 'id');

Isolating the dependency. In a mixed-version codebase, keep usage behind a small helper or repository method so future removal of the polyfill is a one-line change:

final class Row
{
    public static function pluck(array $rows, $column, $indexKey = null)
    {
        return $indexKey === null
            ? array_column($rows, $column)
            : array_column($rows, $column, $indexKey);
    }
}

Migration path. Add a php constraint of >=5.5 to composer.json, then run the test suite and remove the package. On PHP 5.5+ the polyfill never defines anything, so removal is behaviorally safe as long as every environment is genuinely on 5.5+.

CI matrix. If you still ship this, keep a PHP 5.4 (or earlier) job in CI so the polyfill branch is actually exercised; otherwise you are testing the native function and the polyfill rots untested.

Prefer a maintained alternative if you must polyfill today. symfony/polyfill-php55 includes array_column() and is actively maintained; do not pull in both.

Gotchas and Tips

• Archived status is the headline risk. No security patches, no PHP 8 compatibility work, no bug fixes. It happens to be harmless on modern PHP because of the function_exists guard, but it is dead weight.
• Polyfill vs. native semantics are close but not guaranteed identical across every historical PHP version, particularly around objects implementing ArrayAccess/__get and non-array iterables. If your data is not plain arrays, add tests.
• Function redefinition conflicts. Multiple polyfills (this one plus Symfony's, or a framework's) can coexist because of the function_exists guard, but whichever loads first wins. Autoload file order is dependency-graph dependent—do not rely on one implementation's edge-case behavior in a project that requires several.
• Verify what is actually loaded when debugging:

$ref = new ReflectionFunction('array_column');
echo $ref->getFileName(); // vendor path = polyfill; false-ish/internal = native

• Composer files autoloading runs on every request, including CLI commands and workers. The cost here is trivial, but avoid accumulating many such polyfills in performance-sensitive legacy apps.
• Do not reference array_column in code that must run before vendor/autoload.php (e.g., a custom front controller bootstrap or composer scripts). It will fatal on PHP < 5.5.
• index_key with duplicate keys silently overwrites—this is native behavior, but legacy code often assumes uniqueness; validate upstream if correctness matters.
• No extension points. There is no configuration, no class to subclass, no events. If you need different behavior, copy src/array_column.php into your project (MIT license permits it) and drop the dependency.
• Composer constraint hygiene. Do not mark this package as required in libraries that support PHP 5.5+; use "php": "<5.5" in a require-dev or conditional context, or better, let the consuming application add it. Libraries that force it on everyone are a common source of duplicated polyfills.
• Framework integration is passive. Laravel, Symfony, and similar will autoload it once installed; nothing to register in config/app.php or a service provider. Removal is equally passive—just composer remove.