- What is tightenco/overload and how does it work?
- Overload is a single trait that adds runtime method dispatch to a PHP class using __call and reflection, routing each call to the implementation that matches the arguments passed. It requires no service provider, configuration, migrations, or container bindings, and it does not modify the original class source. Architecturally it is a local ergonomics utility rather than infrastructure.
- How do I install tightenco/overload?
- Run composer require tightenco/overload:0.1.3 and add a use statement for the trait in the class that needs overloaded methods. There is no service provider to register and nothing to bootstrap. Before adopting, verify that the illuminate/collections constraint resolves against your installed Laravel version.
- Does tightenco/overload work with Laravel 9, 10, and 11?
- Overload has no Laravel service provider or framework version constraint, and its only runtime dependency is illuminate/collections, so compatibility depends on whether the pinned constraint resolves against your installed Laravel. For Laravel 9 and newer this is the first thing to test and it frequently fails. Treat successful installation as a binary gate before evaluating anything else.
- Is tightenco/overload still maintained?
- No. The repository is archived, the last release was 2020-09-08, it has roughly 113 stars and zero dependents, and there is no upstream fix stream. Any PHP minor that changes reflection, __call semantics, or argument coercion becomes a risk you own outright. Plan for containment or replacement rather than expecting updates.
- Can I use Overload on Eloquent models, controllers, or facades?
- Generally no. Eloquent models, controllers extending framework base classes, facades, and any Macroable class already define __call, which collides with the trait's dispatch mechanism. Since those are exactly the classes where overloading is most tempting in Laravel, the trait is effectively disqualified from the highest-value locations.
- What happens if the arguments do not match any overloaded method variant?
- A type mismatch does not throw an exception in Overload; the call resolves to some candidate variant and executes it. That silent wrong-variant execution is the highest-severity failure mode because it tends to surface in production as incorrect data rather than a loud error. Tests should assert resolved behavior explicitly, and critical call sites should avoid ambiguous signatures.
- Does Overload support PHP 8 features like union types, named arguments, and enums?
- The package predates PHP 8 entirely, so it was not designed around union types, named arguments, enums, match expressions, or constructor promotion. On PHP 8.0 and newer those native language features often eliminate the reason to use runtime overloading in the first place. If your PHP floor is 8.0 or higher, evaluate whether a union type or match expression solves the problem more safely.
- How does Overload affect PHPStan, Psalm, and IDE autocomplete?
- Static analysis tools such as PHPStan and Psalm cannot infer return types through __call, and IDE autocomplete and generated documentation will not understand the overloaded surface. Stack traces terminate at the magic method, and exception messages name __call rather than the resolved variant. Coverage reports also collapse distinct behaviors behind a single method name.
- What are alternatives to tightenco/overload?
- Prefer native PHP 8 features such as union types, named arguments, enums, and match expressions, which give you explicit dispatch with full static analysis. Composition, decorators, subclassing, and Laravel macros are also safer alternatives when you need to extend vendor or framework classes. Overload remains an option only for legacy codebases that cannot otherwise change a class.
- Should we adopt tightenco/overload in a new project or keep an existing dependency?
- For new adoption the answer is almost certainly no: the package is archived, has no upstream fix stream, and predates PHP 8. If you already depend on it, contain usage to a small number of classes, test illuminate/collections resolution on your current Laravel, and write an explicit removal trigger and owner. Any surface shipped to another team or customer should not call through the overloaded methods.