Product Decisions This Supports
- Build-vs-buy for introspection utilities. This package is a thin convenience wrapper over PHP's
Reflection* API for reading private/protected properties, methods, and constants on objects you don't own. The decision it informs is whether your team maintains its own reflection helper or adopts a small MIT dependency — not whether to architect a capability around it.
- Unblocking third-party integration work. When a vendor SDK or legacy domain object hides the data you need (a private ID, an internal config constant, a protected state flag) and the vendor won't expose it, this lets you ship an adapter instead of forking the dependency or waiting on an upstream release. That is a roadmap-unblocking decision with a concrete cost (technical debt) you can schedule for removal.
- Test-tooling scope. Most legitimate use is in test suites: asserting against private constants, constructing objects whose constructors are private, or reaching into final/legacy classes that resist mocking. This supports a "test-only dependency" decision, which is a materially different risk profile from a runtime dependency.
- Migration and backfill scripting. One-off scripts that read protected state out of old objects to populate new schemas. Low blast radius, short lifespan, disposable by design.
- Explicit non-decision: it does not justify redesigning your domain model, and its near-zero adoption (1 star, 0 dependents) means it should never appear on a critical-path architecture diagram.
When to Consider This Package
Adopt only when all of the following hold:
- The need is confined to tests, dev tooling, or throwaway scripts — not request-handling production code.
- You are blocked by a specific, named private/protected member in code you cannot modify (vendor package, frozen legacy module), and the workaround cost (forking, patch-pinning, monkey-patching) exceeds the cost of a small dependency.
- You can wrap it behind your own one-class adapter, so replacement or inlining later is a single-file change.
- You've reviewed the source. It is small enough to audit in an afternoon, which is the only reason a single-maintainer, zero-dependent package is tolerable here.
Look elsewhere — or write twenty lines of ReflectionClass yourself — when:
- The need is on a production hot path, or the package would become a long-lived dependency of shipped code.
- Maintenance and bus factor matter. One maintainer, one star, no dependents, no ecosystem signal. Recent release dates are encouraging but are not a support contract; assume you may own the fork.
- Your codebase already has a reflection helper; a second one is pure fragmentation.
- The target members are likely to be renamed or removed upstream — reflection-based access fails silently or loudly at the worst time, and you inherit that fragility either way.
- You can achieve the outcome through a supported seam: a public getter added upstream, a serialization hook, a test double, or dependency injection. Always prefer the supported seam; treat this as the fallback.
How to Pitch It (Stakeholders)
For executives: This is a tiny, free (MIT) developer utility that lets our engineers read data hidden inside third-party or legacy code without forking those libraries or waiting on vendor roadmaps. The business value is schedule: it removes a class of "blocked on vendor" delays from integration and migration work. The cost is near zero and the risk is containable because we would restrict it to tests and internal tooling, wrap it in our own adapter, and pin the version. It is not a platform bet and does not enter the production architecture. Honest caveat: it is a one-person open-source project with essentially no adoption, so we should plan on the assumption that we, not the author, would fix it if it breaks.
For engineering: Treat it as sugar over ReflectionProperty/ReflectionMethod/ReflectionClassConstant, with the fiddly parts (constant lookup, inherited and static member traversal, uniform error behavior) already handled consistently. Use it in test fixtures and migration scripts; wrap it in a single internal helper class so the dependency is one file deep and trivially replaceable. Do not call it from controllers, services, or anything on a request path. Before merging, read the source — it is short — and confirm behavior against your PHP version; if you'd rather not carry the dependency at all, budget half a day to reimplement the two or three methods you actually use, which is a perfectly rational outcome and should not be framed as a rejection of the tool.