Direct Property Access Laravel Package

Product Decisions This Supports

• Data-mapping / DTO strategy. The package (rekalogika/direct-property-access) sits in the hydration-and-mapping layer: reading and writing object properties without hand-written getters/setters. This is a build-vs-buy input for any decision about how requests, messages, and persisted entities become in-memory objects — do we generate accessor boilerplate, lean on Laravel's fill()/mass assignment, adopt a mapper (e.g. rekalogika/mapper, laravel-data), or use a thin property-access primitive like this one.
• Serializer/mapper dependency selection. Direct property access is the alternative to accessor-driven access (Symfony's PropertyAccess-style "call the getter" model). Any decision to standardize on a mapping approach should record which of these two contracts our DTOs are written against, because it dictates how much boilerplate our domain classes carry and how portable they are across frameworks.
• Framework upgrade roadmap. 1.4.0 is essentially a compatibility release: it widens the constraint to permit Symfony 8 components (allow sf8) and refreshes CI actions. That is a direct input to the "can we move to Symfony 8-line components / the next Laravel major?" question — this package is no longer a blocker on that path, and it signals the maintainer intends to track Symfony's cadence rather than pin to older lines.
• Risk register / dependency tiering. The release contains no features, no deprecations, no behavioural changes — a dependency-and-CI-only delta. That classifies it as a low-risk bump we can absorb in a routine maintenance window rather than a change requiring regression testing of business logic.
• Roadmap hygiene. Because the changelog is dependabot- and CI-driven, it tells us the maintainer is automated but not necessarily feature-active. Useful for deciding whether this stays a "convenience dependency" or needs a named internal owner and a fork/fallback plan.

When to Consider This Package

Adopt when:

• Your DTOs, value objects, or read models intentionally expose plain properties rather than getter/setter pairs, and you need a reliable, single way to populate them (hydration from arrays, mappers, fixtures, importers).
• You are already inside, or migrating toward, the Symfony 8-compatible dependency graph (relevant for Laravel apps on newer Symfony component lines) and want fewer packages capping your upgrade path. 1.4.0 explicitly removes that cap.
• You want a small, single-purpose primitive rather than pulling in a full serializer or mapper just to move values onto an object.
• You need explicit, inspectable property access in code that reviewers and static analysis can follow, as opposed to magic __get/__set or array-casting tricks.

Look elsewhere when:

• You need serialization, normalization, validation, or nested/typed conversion — use symfony/serializer, laravel-data, or a full mapper; this is not that.
• Eloquent's own fill()/$casts/$guarded already covers the use case; adding a second access mechanism invites inconsistency about which layer owns assignment.
• Reflection-based access on a hot path is a measured performance concern in your context, or your code must avoid reflection for static-analysis or AOT/preloading reasons (e.g. strict PHPStan/Rector rule sets, OPcache preloading constraints).
• You require a vendor with a support contract, a public roadmap, or a guaranteed security-response SLA. The 1.4.0 changelog is dependabot and CI bumps only — treat this as a well-behaved hobby-scale dependency and plan a fallback (a ~50-line internal equivalent) if that risk is unacceptable.
• Your team already standardizes on accessor-based mapping and changing that contract would cost more than the boilerplate it removes.

Before adopting, verify in a short spike: supported PHP versions, the exact composer constraints after the Symfony 8 widening (does it still support the Symfony line you are actually on?), and whether the package's access semantics match your readonly/typed-property and promoted-constructor usage.

How to Pitch It (Stakeholders)

To executives: This is a small, narrowly scoped open-source dependency that lets our code populate objects directly instead of writing repetitive accessor code — less code, fewer defects in the mapping layer, no licence cost. The 1.4.0 release contains no new features and no breaking changes; its practical value to us is that it no longer holds back a future Symfony 8 / Laravel major upgrade. Recommendation: approve as a low-risk, low-cost dependency, absorbed in a routine maintenance window, with a named internal owner and a trivial exit path (we could replace it in-house in well under a day) so it never becomes a strategic dependency.

To engineering: 1.4.0 is a compatibility and hygiene release — Symfony 8 permitted in constraints, CI actions refreshed. No API changes, no deprecations, no behaviour changes, so no migration work. Please (1) run the bump through the normal dependency pipeline and confirm our locked Symfony component versions still resolve, (2) add a test that exercises property population on a representative DTO so a future silent behavioural change would be caught, and (3) keep the usage confined to the mapping/hydration boundary — do not let it become a general-purpose back door into private state on domain entities.

To product/architecture: Treat this as an approved utility for the mapping layer only, not a serialization strategy. If we later choose a full mapper or serializer, this package should be re-evaluated rather than carried forward by default. Next review trigger: the next minor release containing actual features or deprecations, or any drop in supported PHP/Symfony versions.