PHP 8.5 y su operador pipe |> : pipelines legibles sin quebraderos de cabeza

26 de septiembre de 2025. Apunta la fecha: PHP 8.5 por fin cae, te guste o no. Entre las novedades, el operador pipe |> te obliga a dejar las paréntesis estilo matrioshka y abrazar pipelines que puedes leer sin sacrificar neuronas.

En este artículo vas a destripar el operador, medir sus límites y, sobre todo, robar casos de uso reales para llevarlo a producción sin fingir miedo.

¿Por qué demonios un pipe en PHP?

En prácticamente todas tus apps encadenas transformaciones: limpiar entrada de usuario, validar un payload, instanciar un objeto, serializar una respuesta… Hasta ahora, dos opciones horribles:

• anidar llamadas (foo(bar(baz($input)))) y rezar para que tu compi del lunes entienda el orden;
• regalar variables temporales ($step1, $step2, $step3) hasta que el archivo parece una libreta garabateada.

El pipe |> te abre un tercer camino: pasa el valor de la izquierda como argumento implícito a la expresión de la derecha. Resultado: código que lees de arriba abajo, igual que piensas cuando tienes café a mano.

Sintaxis: la única regla que importa

La regla es corta: lo que está a la izquierda entra como primer parámetro de la expresión a la derecha. Si la función espera el valor en otra posición, deja ... donde quieres que caiga. No hay ritual, solo tres puntitos.

php
1$resultado = $datos
2    |> trim(...)
3    |> htmlspecialchars(..., ENT_QUOTES, 'UTF-8')
4    |> mb_strtoupper(..., 'UTF-8');

Aquí trim recibe $datos, el resultado pasa a htmlspecialchars y termina en mb_strtoupper. Nada de llaves extra ni variables desechables.

ℹ️ Si la expresión necesita varios argumentos, ... marca el hueco exacto. Si lo olvidas, PHP enchufa el valor en el primer parámetro y te toca depurar el “comportamiento inesperado”.

Caso práctico n.º 1: domar la entrada de un formulario

Piensa en una API que recibe el título de un artículo. Quieres:

1. limpiar espacios sobrantes;
2. limitar a 80 caracteres;
3. asegurarte de que no está vacío;
4. devolver un error decente si se rompe algo.

php
1$title = $payload['title'] ?? '';
2
3$normalizedTitle = $title
4    |> trim(...)
5    |> fn(string $value) => mb_substr($value, 0, 80)
6    |> fn(string $value) => match (true) {
7        $value === '' => throw new InvalidArgumentException('El título es obligatorio.'),
8        default => $value,
9    };

Cada parada del pipeline queda aislada, testeable y fácil de releer. Las funciones anónimas actúan como guardarraíles sin pedirte que montes una clase solo para calmar a un arquitecto ansioso.

Caso práctico n.º 2: maquillar una respuesta HTTP

Imagínate tu microservicio del tiempo escupiendo JSON. El pipe te deja componer la transformación manteniendo cada intención en su carril:

php
1$responseBody = $weatherProvider->fetchForCity('Lyon')
2    |> fn(array $data) => array_merge($data, [
3        'updatedAt' => (new DateTimeImmutable('now', new DateTimeZone('Europe/Paris')))->format(DateTimeInterface::ATOM),
4    ])
5    |> array_map(fn($value) => is_float($value) ? round($value, 1) : $value, ...)
6    |> fn(array $data) => array_intersect_key($data, array_flip(['temperature', 'humidity', 'windSpeed', 'updatedAt']))
7    |> json_encode(..., JSON_THROW_ON_ERROR | JSON_PRETTY_PRINT);

Lees el flujo como una serie de transformaciones limpias. ¿Necesitas logs o métricas? Mete una lambda en medio y sigue con tu vida.

Caso práctico n.º 3: hidratar un objeto de dominio

El pipeline también funciona con métodos estáticos o de instancia mientras acepten el valor como primer argumento. Ejemplo con el Value Object EmailAddress, perfecto para evitar correos escritos con los codos:

php
1$recipient = $input['email'] ?? '';
2
3$email = $recipient
4    |> trim(...)
5    |> mb_strtolower(..., 'UTF-8')
6    |> EmailAddress::fromString(...)
7    |> fn(EmailAddress $address) => ContactPreference::fromEmail($address);

Con ... dentro de EmailAddress::fromString(...) señalas el hueco exacto. Luego puedes encadenar un constructor de agregado o un comando CQRS sin convertir el código en espagueti.

Buenas prácticas para adoptarlo sin drama

• Busca coherencia: cada pipeline debe contar una sola historia. Si mezcla validación, persistencia y render, córtalo en partes antes de que lo hagan en la review.
• Nombra o comenta cuando aporta: una lambda fn($x) => $x no sirve. Prefiere una función tipo sanitizeTitle si la intención no salta a la vista.
• Cuida la lectura vertical: alinea los pipes, deja aire entre bloques lógicos y añade comentarios cortos cuando ahorren dolores de cabeza.
• Piensa en tests: extrae helpers puros (por ejemplo, limitLength) y testéalos aparte. El pipeline queda como orquestación, no como vertedero.
• Respeta los tipos: cada paso debe aceptar y devolver lo que espera el siguiente. Cosas como union types y readonly classes encajan bien con esta vibra funcional si las usas para algo más que presumir en LinkedIn.

Cuándo dejar el pipe en la caja

Por tentador que sea, no es bala de plata:

• Transformaciones con efectos secundarios (emails, peticiones HTTP, escritura en disco) enturbian el flujo. Encapsúlalas en un método explícito y llámalo al final, con todas las letras.
• APIs que esperan el valor como segundo argumento: sí, puedes recolocarlo con ..., pero la lectura se resiente. Escribe un helper y deja de fingir que está todo bien.
• Pipelines mutantes: si ya llevas más de tres lambdas raras, respira, corta la cadena o vuelve al estilo imperativo. No hay premio al pipeline más ilegible.

Cómo colarlo en una base de código existente

1. Mapa de hotspots: localiza los nidos de array_map/array_filter, validaciones de formularios y transformaciones de respuestas.
2. Refactor progresivo: sustituye bloques anidados por pipelines cortos. Añade tests de regresión si quieres dormir tranquilo.
3. Comparte convenciones: documenta cuándo usar el pipe, cómo nombrar helpers y cómo manejar excepciones.
4. Actualiza el tooling: renueva snippets y linters para la nueva sintaxis (php-cs-fixer, Psalm, PHPStan) o tendrás semanas de avisos inútiles.
5. Forma al equipo: organiza una review o un live coding para enseñar la mejora de legibilidad, incluso a la peña que sigue enamorada de PHP 5.

Resumen exprés

• El pipe |> de PHP 8.5 manda el valor de la izquierda a la expresión de la derecha sin variables temporales.
• Añade ... para colocar el valor justo donde lo necesitas o prepárate para bugs fantasma.
• Pipelines cortos y coherentes suben la legibilidad, la testabilidad y la expresividad.
• Reserva el operador para transformaciones puras (o casi); encapsula los efectos secundarios lejos del flujo.
• Pon al día tu ecosistema (linters, estándares, formación) para que la novedad no reviente el resto del proyecto.

El pipe no convierte PHP en un lenguaje puramente funcional, pero te da una herramienta afilada para escribir código moderno y expresivo. Te toca: deja tus cadenas de transformación tan claras como tus ideas… o al menos menos confusas que de costumbre.