Strict Objects Laravel Package

Product Decisions This Supports

• Defensive-programming features and internal SDKs: The trait converts silent, typo-driven failures ("I called $order->totalAmmount and got null") into loud exceptions. That directly improves reliability of domain models, DTOs, and service classes where dynamic property access is a common source of production incidents.
• Build-vs-buy calls for code-quality infrastructure: With 0 dependents, a 2020 last release, and an ambiguous license (NOASSERTION), this is a classic "build, don't buy" decision. The trait is a handful of lines of __get/__set/__call guards — the PM decision is whether to standardize this pattern internally rather than adopt an unmaintained dependency.
• Technical-debt / refactoring roadmap: It supports a "harden legacy service layer" initiative — useful as a cheap, incremental guardrail when migrating a legacy PHP codebase toward stricter typing, rather than a big-bang rewrite.
• Adoption of static analysis vs. runtime guardrails: This package occupies the same problem space as PHPStan/Psalm strictness levels. Choosing it (or building an equivalent) is a decision about when errors surface: at CI time (static analysis) vs. at runtime (this trait). This informs where engineering investment goes.
• Risk/portfolio management: License ambiguity and dormancy make this a supply-chain risk item; the product decision is to avoid adding it to the dependency tree and instead vendor or reimplement.

When to Consider This Package

Consider if:

• You maintain a legacy PHP codebase heavy on dynamic properties, magic methods, or untyped models where typos silently return null.
• Your team is not already running PHPStan/Psalm at a strict level (where the same bugs are caught earlier).
• You need a low-effort, incremental safety net for a specific subsystem (e.g., a billing domain object) rather than project-wide coverage.
• You can fork/vendor the code under a clear internal license and own its maintenance.

Look elsewhere (or build) if:

• The license is unclear (NOASSERTION is a blocker for most legal/compliance reviews).
• You are on PHP 8.2+, where dynamic properties are deprecated natively — the platform now provides much of this guardrail for free.
• Your CI already enforces strict static analysis; the marginal runtime benefit is small and the maintenance burden is real.
• You need an actively maintained dependency with a support contract — 31 stars, 0 dependents, and a last release in December 2020 signal abandonment.

How to Pitch It (Stakeholders)

For executives: This is a tiny, low-cost code-quality utility that turns silent typo bugs into clear errors in PHP classes. The value is real but narrow, and the package itself is effectively unmaintained with an unclear license. Recommendation: do not adopt as an external dependency; instead replicate the ~30-line pattern internally under our own license. Cost is hours, risk is near zero, and it fits a broader "reduce silent failures in legacy services" effort.

For engineering: kdyby/strict-objects is a StrictObject trait that guards __get, __set, and __call so undefined property/method access throws instead of failing silently. It overlaps heavily with what strict PHPStan/Psalm levels already catch at CI time, and PHP 8.2's dynamic-property deprecation covers part of the gap. Given its dormancy and license ambiguity, the ask is to vendor or rewrite the trait in our shared utility package, roll it out to high-risk domain models first, and measure incidents attributable to typo'd member access before expanding scope.