Weave Code
Callable Reflection Laravel Package
technically/callable-reflection
A PHP package for reflecting any callable—closures, invokable objects, function names, and array callables—through a single, consistent API. Inspect parameters, types, defaults, and return types to power dependency injection, routing, and event handling in Laravel or plain PHP.
:call_me_hand: a handy library to reflect and invoke any callable. :elephant: PHP8-ready :tada:
Frequently asked questions about Callable Reflection
- How do I reflect any PHP callable in Laravel without writing branching logic?
- technically/callable-reflection normalizes every callable form into a single ReflectionFunction or ReflectionMethod instance. You pass a closure, invokable object, array callable, or function string and get back the correct reflection object. From there you can inspect parameters, types, defaults, and return types with the standard PHP reflection API. It is framework-agnostic but works cleanly inside Laravel services, action registries, and configuration-driven callbacks.
- Does technically/callable-reflection support invokable objects and array callables like [$object, 'method']?
- Yes. The package accepts closures, first-class callable syntax, invokable objects, [$object, 'method'], [Class::class, 'method'], 'Class::method', and plain function name strings. Each is resolved to the appropriate ReflectionFunction or ReflectionMethod, so you do not need your own match statement or instanceof checks. This is especially useful when callables come from package configuration or user-supplied extensions.
- How do I install technically/callable-reflection with Composer?
- Install it with composer require technically/callable-reflection. The package is framework-agnostic and ships no service provider, facade, config file, or migrations, so there is nothing to register in a Laravel app. Because it is pre-1.0, pin the dependency to the current 0.x minor line rather than the major to avoid surprise breaking changes.
- Which PHP and Laravel versions does technically/callable-reflection support?
- The 0.5.0 release advertises PHP 8.5 compatibility, and the package targets modern PHP with features such as enums, readonly properties, union and intersection types, and never return types. There is no Laravel version constraint because there is no Laravel integration layer. Before relying on the PHP 8.5 claim, add 8.5 to your own CI matrix and verify deprecation behavior, not just that the package installs and runs.
- Is technically/callable-reflection a replacement for Laravel's app()->call() or the container?
- No. Laravel's app()->call() already resolves type-hinted dependencies and is the right tool for invoking controller-like methods. This package overlaps on invocation but its primary value is reflection and parameter introspection, not dependency resolution. Use it at seams where user-supplied callables enter the system as configuration, such as pipeline stages, handler registries, or custom validation callbacks.
- How do I inspect a callable's parameter types, defaults, and return type?
- Resolve the callable through the package and you receive a ReflectionFunction or ReflectionMethod. From that object, use getParameters(), getReturnType(), and the usual ReflectionParameter methods to read types, defaults, optionality, and by-reference flags. This makes it straightforward to build validation, dynamic invocation, or metadata-driven behavior around callables supplied by package consumers.
- What are the risks of using a pre-1.0 package like technically/callable-reflection in production?
- The package is at 0.5.x, and under semver a 0.x minor bump may include breaking changes, so the reflection surface is not contractually frozen. Pin to the 0.x minor line and keep a thin adapter boundary so an API rename stays a contained edit. The project also has a small maintainer set, low star count, and zero dependents, so treat upstream activity as a signal to monitor rather than a guarantee.
- Does technically/callable-reflection handle by-reference parameters, variadics, and union or never types?
- Those are standard PHP reflection edge cases, and the package does not change how they behave. You should still test by-reference arguments through invokeArgs(), variadics combined with named arguments, static versus bound closures, private and protected visibility for string callables, and union, intersection, and never return types. The 0.5.0 release only claims PHP 8.5 compatibility and does not alter this behavior, so your test matrix obligation is unchanged.
- How should I test callables reflected with technically/callable-reflection in Pest or PHPUnit?
- Cover each callable shape your application accepts: closures, invokable objects, array callables, and function strings. Assert the returned reflection class, parameter count, defaults, and return type for representative cases, then add edge cases such as variadics, by-reference parameters, and named arguments. Include PHP 8.5 in your CI matrix if you intend to rely on the compatibility claim in 0.5.0.
- What alternatives exist to technically/callable-reflection for reflecting callables in PHP?
- You can branch manually between ReflectionFunction and ReflectionMethod, or use Closure::fromCallable() to normalize callables before reflection. Laravel's app()->call() and the Illuminate container cover invocation and dependency resolution but are not a reflection API. This package is a small, focused utility, so weigh its convenience against the maintenance risk of a pre-1.0 dependency with a single-maintainer namespace.
Weaver
How can I help you explore Laravel packages today?