tightenco/overload
Overload by Tighten adds method overloading to Laravel and PHP, letting you define multiple methods with the same name and dispatch each call to the right implementation based on the arguments passed—keeping controllers and services clean and expressive.
Internal API and SDK surface design. The concrete decision this package informs is a naming-and-convention call: should an internal service expose one polymorphic entry point (find(int $id) vs. find(string $slug)), or two explicitly named ones (findById / findBySlug)? That conversation is worth having once, with the team, regardless of whether the package is ever installed. Use it as the framing artifact in a design review, not as the answer.
Build vs. buy vs. reject — with a decided answer. If the team wants overload-style ergonomics, the realistic options are: (a) 100–200 lines of hand-rolled __call plus reflection, (b) this package, or (c) reject the pattern in favor of PHP 8 union types, named arguments, enums with match, or plain explicit method names. With the repo archived, ~113 stars, zero dependents, and a final release in September 2020, "buy" is not a live option. The decision is genuinely between (a) and (c), and (c) is cheaper, safer, and better supported by tooling. This package's chief value to a PM is making that fork in the road explicit and cheap to close.
Tech-debt scoping and prioritization. Where overload-style dispatch already exists — often a Java or C# mental model carried into PHP — treat it as a schedulable cleanup input, not a project. Slot "replace magic dispatch with union types and explicit names" into an existing debt sprint. It's a days-scale refactor per domain area, reversible at every step, with a concrete debuggability payoff: that combination makes it easy to justify and easy to defer without accumulating named risk.
Domain-model expressiveness calls. Whether polymorphic, type-driven dispatch belongs inside a domain object at all — versus a strategy pattern, per-shape factory methods on a value object, or a match over a discriminated value. Overloading quietly encourages branching on argument types inside a class, which is harder to test, harder to trace, and harder to review. A PM steering design reviews should push toward explicit, testable construction here.
The DX quality bar for anything shipped outward. Magic dispatch breaks IDE autocomplete, static analysis return-type inference, generated docs, and readable stack traces. All of those are part of the perceived quality of a developer-facing product. This package clarifies where the bar sits: acceptable inside a throwaway internal script, unacceptable in a public package, SDK, or anything a customer or another team integrates against.
Supply-chain and dependency-review policy. Zero dependents and no release since 2020 make this a clean reference case for a default-reject rule in dependency review — and a useful precedent the next time a convenience library with stale metadata comes up for approval.
Evaluation hygiene and metadata trust. The package's own description is thin and partly inconsistent with its actual method-overloading behavior, and the only recent release note is a Collect compatibility bump. Treat that combination — small, archived, poorly described — as one compounded risk, and verify claims against source before any pilot.
Consider it only if all of the following hold:
Macroable. In Laravel, precisely the classes most likely to want overloading (Eloquent models, controllers, facades) already own __call, so the trait collides and cannot be cleanly applied. That is disqualifying, not merely inconvenient.Look elsewhere — or redesign — when any of these hold:
match remove most of the original motive. find(int|string $key) is one line and needs no dependency.match over a discriminated value. If a reviewer can't tell from the signature what the method accepts, the ergonomic gain isn't real.For executives — one paragraph. A small, archived Tighten package that adds Java-style method overloading to PHP classes. We evaluated it as a build-vs-buy-vs-reject input, not as a purchase. Recommendation: do not adopt it for new work. The repo is archived, has had no release since September 2020, predates PHP 8, and has zero dependents — meaning no upstream fix stream and no compatibility guarantee. PHP 8 already gives us the same expressiveness with union types and named arguments at zero dependency cost. Where the pattern already exists in our codebase, we treat removal as ordinary scheduled debt (days per domain area, reversible at each step), not as a project. The evaluation itself is reusable: it becomes our reference precedent for default-rejecting stale convenience libraries in dependency review.
For engineering — the ask. If a team wants overload ergonomics, the honest options are hand-rolling __call plus reflection, or rejecting the pattern. Rejecting is cheaper, safer, and better supported by our tooling. If it's already in the tree: pin 0.1.3, confirm no illuminate/collections conflict against your Laravel version, contain it to an allowlisted set of leaf namespaces enforced in CI, add one dispatch test per variant plus a no-match test (your suite is the only spec — static analysis can't see through __call), and standardise declare(strict_types=1); across calling code, because the caller's strictness silently changes which variant fires. Wrap the overloaded method behind explicit findById / findBySlug methods, migrate call sites per class, delete the trait last. Write the exit trigger down before you start — "removed by the next PHP minor upgrade" — and hold it. Treat silent wrong-variant execution, not the archived repo, as the primary risk: a type mismatch resolves to some candidate and runs it, and you find out in production.
The line to remember. Borrow the ergonomics idea if the team likes it; don't inherit the dependency.
How can I help you explore Laravel packages today?