Or Else Laravel Package

Product Decisions This Supports

• Code Reusability & Consistency: Standardize fallback logic across Laravel/PHP applications by providing a uniform orElse pattern, reducing ad-hoc implementations (e.g., ??, null checks, or ternary operators).
• Developer Productivity: Accelerate development cycles for teams by eliminating boilerplate fallback logic in queries, collections, or service responses (e.g., API payloads, database results).
• Roadmap Alignment: Prioritize internal libraries or frameworks where fallback logic is critical (e.g., data pipelines, caching layers, or error-handling middleware).
• Build vs. Buy: Opt for this package over custom solutions if your team lacks time/resources to maintain a reusable fallback mechanism, or if you’re avoiding reinventing a simple but repetitive pattern.
• Use Cases:
  • API Responses: Replace manual checks for null/empty responses with orElse (e.g., User::find($id)->orElse(new User())).
  • Database Queries: Simplify fallback logic for optional relationships (e.g., Post::with('author')->find($id)->author->orElse(new Author())).
  • Collections: Standardize empty-state handling (e.g., users->filter()->orElse(collect([]))).
  • Legacy Code Modernization: Retrofit existing projects with a consistent fallback pattern without breaking changes.

When to Consider This Package

• Adopt if:
  • Your team frequently writes repetitive fallback logic (e.g., ??, empty(), or is_null() checks).
  • You’re building a Laravel/PHP application where consistency in error handling or data pipelines is a priority.
  • You need a lightweight, MIT-licensed solution with minimal overhead (no dependencies, ~50 lines of code).
  • Your stakeholders value maintainability over micro-optimizations (performance impact is negligible).
• Look elsewhere if:
  • You require advanced fallback logic (e.g., async fallbacks, complex conditional logic) → Consider custom traits or libraries like laravel-optional.
  • Your project uses PHP 8.1+ and you prefer native nullsafe operators (?->) over traits.
  • The package’s last release (2015) is a dealbreaker for long-term support (though it’s stable and MIT-licensed).
  • You need type safety beyond basic fallbacks (e.g., return type guarantees) → Use PHP 8.0+ return types or generics.
  • Your team prefers functional programming (e.g., tap(), when()) over method chaining → Explore spatie/array-to-object or laravel-collective/macroable.

How to Pitch It (Stakeholders)

For Executives: "This package lets our PHP/Laravel teams replace repetitive ‘null check’ code with a single, reusable orElse method—like Ruby’s ||= but for objects. It’s a 10-minute setup that saves hours of debugging inconsistent fallbacks in APIs, queries, or collections. Think of it as a ‘default value’ superpower for our codebase, with zero risk (MIT license, no dependencies). Ideal for projects where data reliability matters, like user profiles or payment processing."

For Engineers: *"Spatie’s or-else trait adds orElse() to any class, turning this:

$user = User::find($id) ?? new User();

into this:

$user = User::find($id)->orElse(new User());

Pros:

• Consistent syntax across the codebase.
• Works with Eloquent models, collections, or custom objects.
• Zero performance cost; just syntactic sugar. Cons:
• Last updated in 2015 (but battle-tested and MIT-licensed).
• Not a silver bullet for complex fallbacks (e.g., async or typed defaults). Use it where: You’re tired of ?? or empty() checks, or need to standardize fallback logic in a Laravel monolith."*

For Architects: *"This is a low-risk, high-reward addition for teams prioritizing:

1. Code consistency (avoid ?? sprawl).
2. Maintainability (centralized fallback logic).
3. Laravel ecosystem alignment (works seamlessly with Eloquent/Collections). Alternatives:

• Custom trait: If you need PHP 8.1+ features or stricter typing.
• Native PHP: If using PHP 8.1+ and ?-> suffices. Recommendation: Pilot in a non-critical module (e.g., API responses) to measure developer satisfaction before wider adoption."*