Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better definition for ParameterDefinitionInterface #24

Open
moufmouf opened this issue Dec 11, 2015 · 3 comments
Open

Better definition for ParameterDefinitionInterface #24

moufmouf opened this issue Dec 11, 2015 · 3 comments

Comments

@moufmouf
Copy link
Contributor

So far, the text in the PHPDoc of ParameterDefinitionInterface says this:

Represents a container entry that is a scalar value.

Note: according to is_scalar doc, arrays are NOT "scalar" values.

In the unit tests, we have this: https://github.com/container-interop/definition-interop-tests/blob/master/src/AbstractDefinitionCompatibilityTest.php#L166-L176

Obviously, our parameter definitions is returning an array. Furthermore, the test adds references in the array, which are not scalar either.

I think the test is correct, but that means we need to work on the PHPDoc of the ParameterDefinitionInterface.

Shall we try something like this:

Represents a container entry that is a parameter.

A parameter is a scalar value, a reference, or an array of parameters:

PARAMETER = [scalar | ReferenceInterface | array<PARAMETER> ]

Also, since we are allowing ReferenceInterface into parameters, shall we not extend it to DefinitionInterface?

In this case, we would have:

PARAMETER = [scalar | DefinitionInterface | array<PARAMETER> ]
@Anahkiasen
Copy link

To me ParameterDefinition can be literally anything, it represents a low-level entry in a container, I don't think we should even define explicitly what it can hold, and instead just say like, mixed

@moufmouf
Copy link
Contributor Author

mixed is really problematic when it comes to compiled containers (Symfony, Yaco...)
For those, at the very least, you have to be able to "serialize" or "var_export" what ParameterDefinition is returning.

So this rules out resources and non serializable objects which are part of "mixed".

Also, we need Symfony compatibility out of the box, so we might have a look at what Symfony does support for parameters (and restrict ourselves to this subset)

@Anahkiasen
Copy link

Ah yes right mixed would include resources and Closures and such. Too bad PHP doesn't have a serializable type :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants