Curry Laravel Package

Product Decisions This Supports

• Adoption of functional programming patterns in PHP/Laravel: Enables cleaner, more modular code by leveraging partial function application for reusable logic (e.g., middleware, event listeners, or service method wrappers). Aligns with Laravel’s growing support for functional constructs (e.g., tap(), when(), unless()).

• Roadmap for asynchronous Laravel extensions: If expanding Laravel into async workflows (e.g., WebSockets, real-time processing), this package (or its replacement, react/partial) provides a bridge to ReactPHP’s event-driven architecture. Justifies investment in async infrastructure for high-scale applications.

• Build vs. Buy for functional utilities: Avoids reinventing partial application logic, reducing dev time. However, the deprecated status shifts the decision toward react/partial as a "buy" with lower risk. For teams already using ReactPHP, this is a low-effort add-on; for others, it’s a high-maintenance dependency.

• Use cases:

  • Middleware composition: Pre-bind middleware arguments (e.g., Authenticate::withRole('admin')).
  • Event-driven workflows: Partial event listeners (e.g., UserCreated::notify($user, 'welcome')).
  • Service method abstraction: Wrap complex service calls with pre-set parameters (e.g., OrderService::createForUser($userId)).
  • Testing: Simplify test doubles by partially applying mock methods.

When to Consider This Package

• Adopt if:

  • Your Laravel app already uses ReactPHP (e.g., for WebSockets, async tasks) and needs partial function application.
  • You’re building a niche functional programming feature (e.g., a DSL or math library) where partials add clarity.
  • You’ve evaluated alternatives (e.g., Laravel closures, react/partial) and confirmed this fits better for your async use case.
  • Your team has experience with ReactPHP to mitigate integration risks.

• Look elsewhere if:

  • You’re not using ReactPHP: Laravel’s built-in closures (Closure::bind()), dependency injection, or native PHP functions (e.g., array_unshift() for partial-like behavior) suffice.
  • You need true currying (multi-step partial application): Use react/partial or libraries like dnoegel/php-function.
  • Your app is synchronous-only: The async overhead and ReactPHP dependency aren’t justified.
  • You prioritize long-term maintainability: The deprecated status and lack of Laravel integration make this a high-risk choice unless migrating to react/partial immediately.

How to Pitch It (Stakeholders)

For Executives: "This package lets us write more modular, reusable code by pre-configuring functions with fixed arguments—similar to how middleware or event listeners work in Laravel. For example, we could pre-set a user role in authentication middleware or simplify event triggers by binding default values. It’s particularly useful if we’re expanding into real-time features (like WebSockets) where ReactPHP’s async model fits. The trade-off? It’s a niche tool with minimal Laravel support, so we’d need to commit to ReactPHP’s ecosystem. The safer bet is its replacement, react/partial, which we can adopt with almost no code changes."

For Engineering: *"This is a lightweight way to implement partial function application in PHP, but it’s deprecated—so we should use react/partial instead. It’s a drop-in replacement with the same API. The value comes in:

• Cleaner code: Avoid repeating arguments in closures (e.g., middleware, event listeners).
• Async integration: Works seamlessly with ReactPHP if we’re using it for WebSockets or background tasks.
• Functional patterns: Useful for teams adopting FP in PHP, though Laravel’s OOP-first approach may limit adoption.

Risks: Deprecation, ReactPHP dependency, and minimal Laravel-specific tooling. If we’re not using ReactPHP, this is overkill—Laravel’s DI container or closures will work just as well."*