Propfunc Laravel Package

Product Decisions This Supports

• Internal Developer Productivity (DVP):

  • Reduces boilerplate for property access logic by centralizing it in __propGetName/__propSetName hooks rather than scattering manual accessors across classes.
  • Enables faster prototyping, especially in data-heavy domains (admin panels, APIs, CMS models) where properties follow a uniform pattern.
  • Supports "build vs. buy" by replacing repetitive custom accessor plumbing with a small, maintained dependency.

• Consistency & Maintainability:

  • Standardizes property access patterns and now uses an explicit, predictable camelCase naming convention (__propGetName, __propSetName), which improves readability and makes code review easier.
  • The v2.0.0 release clarifies the package's actual mechanism — it is built on PHP magic methods (__get, __set). Teams that adopt it should do so knowingly rather than under the assumption it avoids magic methods.
  • Legacy Gt\PropFunc namespace remains autoloadable, giving teams a low-risk migration path from v1.x to v2.x.

• Upgrade / Release Management:

  • v2.0.0 is a breaking major release: hook names and namespace casing changed. This is a planning decision (scheduled upgrade window, one-time rename), not an adoption blocker.
  • The addition of SECURITY.md and refreshed CI (PHP 8.1+ target, Dependabot updates) signals active maintenance — a positive update versus the prior "last release in 2021" concern.

• Roadmap Prioritization:

  • Justifies investment in Laravel/PHP projects where property access is a recurring friction point.
  • Enables faster MVP iteration by offloading property access logic to a reusable package.

• Use Cases:

  • Admin Dashboards: Standardized property access for user/profile data speeds up UI development.
  • APIs: Consistent handling of property access/mutation in payload assembly.
  • Legacy System Modernization: The Gt\PropFunc autoload fallback allows incremental migration of existing models.

When to Consider This Package

• Adopt if:

  • You are on PHP 8.1 or later (now a hard requirement in v2.0.0).
  • Your application has many classes with repetitive property access logic that fits a uniform pattern.
  • You are comfortable with magic methods (__get/__set hooks) as an explicit design choice — this package is fundamentally built on them.
  • You want a small, actively maintained dependency with a working legacy-namespace fallback path for incremental migration.
  • You are starting a v2.x adoption and can name hooks using the new __propGetName/__propSetName convention from day one.

• Look elsewhere if:

  • Your properties require complex logic (computed fields, business rules, cross-property validation) — use Laravel casts, custom accessors, or purpose-built packages.
  • You need fine-grained control over dynamic attribute names or conditional access.
  • Your team explicitly wants to avoid magic methods for explicitness — despite the prior assessment's framing, this package uses them by design.
  • You are still on PHP < 8.1 and cannot upgrade.
  • You are on non-Laravel PHP needing broader cross-framework support — though as a vanilla PHP package it can work standalone, the assessment is scoped to Laravel usage.
  • You are already using a mature alternative like Spatie's Laravel Model Generator or native $casts/$appends and see no boilerplate pain.

• Migration note (breaking change):

  • Rename hooks: __prop_get_name → __propGetName, __prop_set_name → __propSetName.
  • Namespace updated to GT\PropFunc; the legacy Gt\PropFunc namespace still autoloads, so upgrades can be staged.

How to Pitch It (Stakeholders)

For Executives: "This package reduces boilerplate for property access in our Laravel apps, cutting development time on CRUD-heavy features. Version 2.0 just shipped — it's a breaking change, but a small one: a one-time rename of property hooks and a PHP 8.1+ requirement (which we already meet or should adopt). Importantly, this release also adds a security policy and refreshes CI, which directly addresses the earlier concern that the project might be unmaintained. It's a low-risk, low-effort upgrade that keeps a productivity tool alive for the team."

For Engineering: *"PropFunc v2.0.0 is a breaking release: hooks change from __prop_get_name/__prop_set_name to __propGetName/__propSetName, and the namespace is now GT\PropFunc (the old Gt\PropFunc namespace still autoloads, so we can migrate incrementally). PHP 8.1+ is now required. Note that the package is built on __get/__set magic methods — the earlier assessment framed it as avoiding them, which was inaccurate; we should adopt with that in mind.

• New projects: use the camelCase hooks from day one.
• Legacy code: migrate class-by-class using the autoload fallback.
• APIs: standardize property access for consistent payloads. Plan the upgrade as a scoped task: audit existing hook names, rename, and bump the PHP requirement. Given the SECURITY.md addition and active CI, maintenance risk is now materially lower than the previous assessment implied. I'd recommend a time-boxed spike on a single module, then a full rollout."*