silktide / syringe Goto Github PK

It doesn't seem possible to escape things such as:

parameters:
  atuinclient.atuinPathTemplate: "https://api.atuin.silktide.com/service/%SERVICENAME%"

results in:

Silktide\Syringe\Exception\ReferenceException: Error with key 'atuinclient.atuinPathTemplate'. Tried to inject the parameter 'SERVICENAME' in an argument list, but it doesn't exist

(as % is in indicator for expansion). Doubling up the % or escaping them with backslashes doesn't work (latter results in Could not load the YAML file '/...syringe.yml': Found unknown escape character "\%" at line 2, doubling the backslashes returns to the original error).

We should probably write some. Some parts of this project are... non-intuitive.

When including dependancies with their own dependancies, your dependancies currently need to refer themselves using their own namespace or the project won't work.

For example:

Project MasterProject contains SubProject which contains SubSubProject

If subproject has a syringe.yml of:
api_key: "Hello"
sub.subproject.api_key: "%api_key%"

The SubProject will not correct propagate the api_key.

Uch, this issue is confusing to try and explain, but those involved know what I mean :P

For applications running PHP7.2, adding a tag to a service, generates the following warning

Warning: count(): Parameter must be an array or an object that implements Countable in /application/vendor/silktide/syringe/src/TagCollection.php on line 15

This is because the services property is not initialised before it is counted

This is a proposal to allow PHP constants to be used in Syringe configuration.

Where a method argument is an enumerated value, it is often the case that a PHP constant will be used to represent the value so that if that value needs to change for some reason, no code other than the constant definition is required to change.

Currently, if such an argument is used in a service constructer or method call, the raw value must be specified. This means there is more than one place where the value of the constant is present, removing a lot of the usefulness of the constant.

We could define another character (perhaps ^, but other ideas are welcome) to represent constants that are to be injected into a service. Use of PHPs class constant syntax would be acceptable and I would envisage that parameters could be used within this to allow for the following:

parameters:
    namespace: "Silktide\\Syringe"

services:
    test:
        class: ...
        arguments:
            - "^%namespace%\\Type::STRING"
            - "^%namespace%\\Reason::WHY"

At the moment with larger projects parsing the Yaml is starting to take a large amount of time.

After discussion, the best way to fix this is probably to create a build step caching layer, allowing us to compile the config into a single easily loadable file.

When extending an abstract service, it should be possible to reference it using the standard @service notation.

Currently it matches the entire value, so instead of finding a service named service it would look for @service which won't exist

This is a proposal to implement Symfony style private services.

When required packages define their own DI configuration for a parent package to use, often not all of the services will need to be available for other services to inject. In fact it is sometimes desirable for services to be hidden from other packages, in order to prevent misuse or for application security and consistency.

Symfony's DI container has the concept of a private service, which can only be referenced by services it's own encapsulated DI configuration. We could leverage Syringe's alias namespace system to prevent access to services from outside of those service's namespaces.

For example, consider the following scenario:
The normal service payment.processor can be injected into the service shop.checkout and used for processing payment details. However, we wouldn't want the service payment.cardValidator to be injectable in the same way, as the checkout has no business asking for card numbers to be validated directly. If the card validater service was private, it would only be available for injection into the processor service as they are in the same payment namespace

This concerns aliases of private services within the same namespace; aliasing a private service from another namespace will not work (as you would expect).

This is an edge case that will rarely be an issue, but either needs documenting or correcting. If you have an alias of a private service (all within the same namespace), the current behaviour exposes that alias to the container without obfuscating it's key. A service in another namespace can then reference the alias and access a service that was meant to be private.

#private.yml - aliased with "private"
services:
    privateService:
        #...
        private: true

    privateAlias:
        aliasOf: "@privateService"

#public.yml
services:
    failingService:
        #...
        arguments:
            - "@private.privateService" # This will fail as expected

    ignorePrivacyService:
        #...
        arguments:
            - "@private.privateAlias" # This works when it shouldn't