Container Laravel Package

Getting Started

Start by installing the package via Composer: composer require phpbench/container. The core API is intentionally minimal: instantiate PhpBench\Container\Container, register services via register($id, $factory, $tags = []), and resolve them with get($id). For parameters, use setParameter($name, $value) and getParameter($name). The first real-world use case is typically bootstrapping a small app or library: register core services (e.g., a logger, database client) in register() calls or via an extension class. Check the README’s Simple usage and Extending and Tagging sections first—they cover the most common patterns. Initial setup often involves creating a config class or Extension to centralize registrations.

Implementation Patterns

• Configuration via Extension: Use ExtensionInterface implementations to encapsulate related service definitions and defaults (getDefaultConfig()). Pass them to the container constructor before init().
• Tag-based grouping: Tag services (e.g., [ 'tag' => ['priority' => 10] ]) and iterate over them using getServiceIdsForTag($tag)—ideal for plugins, middleware, or event subscribers.
• Parameter normalization: Parameters use snake_case in config (e.g., 'foo_bar') but are accessed as fooBar in services via $container->getParameter('foo_bar')—this improves interoperability with YAML/JSON configs.
• Lazy or shared services: By default, services are shared. To disable sharing, pass Container::SCOPE_PROTOTYPE as the third argument to register().
• Container-interop compliance: You can swap this container for any other compliant implementation (e.g., Symfony’s container) with minimal changes if contracts like Psr\Container\ContainerInterface are used.

Gotchas and Tips

• init() must be called explicitly after passing extensions to the constructor—services won’t be registered until then. Forgetting this is a common source of “service not found” errors.
• Tag parameter access: Tag metadata (e.g., ['tag' => ['param1' => 'foobar']]) is only available via getServiceIdsForTag($tag) which returns a map of serviceId => metadataArray. Missing metadata defaults to empty array, so validate before use.
• Service name vs ID: The service ID (e.g., 'my_service') is the key used in get(), register(), and tag lookups—not the class name. Consider using class names as IDs for convention-over-configuration.
• Parameter naming inconsistency: Parameters use snake_case in config (e.g., 'foo_bar') but are converted to camelCase internally (fooBar) when accessed via getters—but only when using Container::getParameter(); direct array access on config defaults uses snake_case. This can trip up developers mixing manual config and extension defaults.
• Extensions order matters: Extensions passed to the constructor are loaded in order; later extensions can override parameters or services registered earlier.
• Debugging tip: Use Container::has($id) to avoid exceptions when checking for optional services before get().
• No autowiring: This container does not support autowiring—dependencies must be explicitly declared via constructor arguments or setters in the factory closure.