Object Factory Laravel Package

Product Decisions This Supports

• Extension/plugin architecture design. Whether to build extension points where third parties register behavior declaratively (class + args + calls in configuration) rather than shipping code changes to core. This library is the primitive that makes that pattern cheap instead of bespoke.
• Build vs. adopt vs. own. For internal frameworks that need "construct an object from a spec," adopting this is a viable middle path between hand-rolling a factory and pulling in a full DI container — it's small, single-purpose, and has essentially no dependency surface.
• Who owns configuration. It supports the MediaWiki model where integrators/sysadmins wire features through config files. That's a real product decision about whether your users get declarative control or must go through engineering.
• Use cases: service registries, content-handler/API-module registration, mapping strings from config to classes (replacing giant switch statements), building test doubles from specs, and deserializing behavior from JSON/YAML/PHP config.
• Maintenance-risk decision. 5 stars and 0 dependents means effectively zero external community. The code is small enough that "vendor it and own it" is a legitimate call, but that's a resourcing decision, not just a technical one — budget for it explicitly.

When to Consider This Package

Consider it when:

• You're in PHP and objects must be constructed from data (config, JSON, DB rows), especially with post-construction method calls (calls) — that's the distinguishing feature versus most containers.
• You need a tiny, dependency-free primitive, not a framework.
• You're in or adjacent to the MediaWiki ecosystem — this is a split of MediaWiki core, so semantics and docs line up.
• GPL-2.0 is acceptable to your legal posture.
• You prefer stable-and-quiet over fast-moving; the API is small and settled.

Look elsewhere when:

• You need autowiring, scopes, lazy proxies, tags, or compile-time validation — use Symfony DI, PHP-DI, or Laravel's container. Laravel's container covers ~90% of this out of the box.
• You're shipping proprietary or closed-source software — GPL-2.0 is a hard blocker, not a footnote.
• You need ecosystem support, tutorials, security SLA, or a contributor community. Note the repo is a Gerrit mirror; contributions go to Wikimedia's Gerrit, not GitHub PRs — factor that into your team's workflow.
• It's on a hot path where reflection per construction matters (cache the results or generate factories).
• You need spec validation before runtime — this fails at construction time, not at config-load time.

How to Pitch It (Stakeholders)

To executives: This is a small, battle-tested utility extracted from MediaWiki — the software behind Wikipedia — that lets us assemble features from configuration rather than code. It lowers the cost of adding extension points and lets configuration owners change wiring without a deploy. Two risks to flag: the GPL-2.0 license needs legal sign-off, and external adoption is negligible (5 stars, 0 dependents), so we'd be owning it ourselves. The mitigating factor is that it's a few hundred lines with a single entry point — ownership is cheap.

To engineering: Single-purpose, no runtime dependencies, one main API (ObjectFactory::getObjectFromSpec) supporting class names, factory callables, positional/named args, and post-construction method calls. The trade-off versus a DI container is deliberate: less magic, no autowiring, no ecosystem — but also no framework coupling and nothing to learn. Recommendation: adopt only if declarative, spec-based object construction is an actual product requirement (third-party extension registration, config-driven behavior). If you just want dependency injection, use what you already have.