Xphp Symfony Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy / build vs. adopt on the language layer: XPHP is an emerging PHP dialect (generics-style syntax compiled/transpiled into PHP). This bundle is the Symfony-side integration surface. The decision it informs is whether your team standardizes on XPHP at all — the bundle itself is a thin adapter, so it matters only as a proxy for XPHP core maturity and framework coverage.
• Roadmap timing for framework integrations: v0.2.0 is a pure dependency-tracking release — it bumps the bundle to XPHP v0.2.0 and adopts the new turbofish instantiation syntax (::<T> style generic instantiation). This tells you the integration layer is still churning in lockstep with the language spec, roughly one release behind core. Expect that cadence to continue; do not plan adoption on a stable integration contract yet.
• Framework coverage signal: the existence of an official Symfony bundle (and sibling Laravel packages) is evidence XPHP is pursuing the "drop into existing PHP frameworks" strategy rather than a greenfield runtime. That's a favorable signal for incremental adoption inside an existing Laravel/Symfony codebase versus a full rewrite.
• Developer-experience bet: turbofish syntax is a syntax-ergonomics decision, not a capability one. If your team has strong opinions on generic instantiation ergonomics (or existing XPHP code that used the older instantiation form), this release forces a source-level migration in your XPHP code, not in your PHP application code.
• Use cases where this is worth a spike: library/SDK authors wanting parametric types without leaving PHP; teams already committed to PHP tooling (Composer, PHPUnit, static analysis) who want generics without adopting a new runtime or FFI boundary.

When to Consider This Package

Consider it when:

• You are a Symfony shop (note: this specific bundle is Symfony-first — for a Laravel codebase, look at the corresponding Laravel integration package in the same xphp-lang org, not this one) already using or evaluating XPHP.
• You have a concrete, bounded module where generics meaningfully reduce duplication (collection/result/option types, typed repositories) and you want it inside an existing Symfony app rather than a parallel codebase.
• You can absorb pre-1.0 churn: v0.1.0 → v0.2.0 already includes a source-breaking syntax change in the language layer, and the bundle followed within one release. Pin exact versions and budget for migration work each bump.
• Your build pipeline can accept an added compile/preprocessing step and the corresponding debugging story (stack traces crossing the transpile boundary, IDE support, static-analysis integration).

Look elsewhere when:

• You need production stability guarantees — 0.x versioning with language-level syntax churn is the opposite of that.
• Your team is Laravel-based: this bundle's code targets Symfony's bundle/DI model. Reassess against the Laravel-side package instead; the decision criteria above transfer, the artifact does not.
• You want generics today with zero ecosystem risk: native PHP tooling (phpstan generics annotations, @template) or a mature language with first-class generics is the lower-variance path.
• You cannot tolerate lockstep upgrades — a bundle whose only v0.2.0 change is "track core v0.2.0" implies you cannot upgrade the bundle independently of the language runtime.

How to Pitch It (Stakeholders)

For executives — one paragraph: XPHP is an experimental extension to PHP that adds generics-like type safety while keeping existing PHP frameworks and tooling. This Symfony bundle is the official integration layer. The v0.2.0 release is a maintenance update: it upgrades the bundle to track XPHP core v0.2.0 and adopts a revised generic-instantiation syntax. There are no new capabilities and no security fixes — the release is a signal, not a feature. The signal is that the project is actively maintained and keeps its framework integrations current, but it also confirms the project is pre-1.0 and still changing its source-level syntax between minor versions. Recommendation: fund a timeboxed technical spike in a non-critical module, not a production commitment; do not schedule adoption work until the language syntax stabilizes at 1.0.

For engineering — the short version:

• Bumps to XPHP v0.2.0 core; the only change is migrating to turbofish instantiation syntax (::<...>). Treat as source-breaking for existing XPHP code even though the bundle version went 0.1 → 0.2.
• Pin xphp-lang/* to exact versions; never use caret ranges across minor bumps until 1.0.
• Validate that your IDE, static analysis, and stack-trace tooling still behave across the transpile boundary before expanding usage.
• The bundle is thin — most risk and most value live in XPHP core, so evaluate core first; the bundle is a packaging detail.