Identifier definition is needed
shochdoerfer opened this issue · comments
I just ran into an issue trying to figure out if Disco is able to work with Expressive. In theory it should work since Disco implements container-interop and Expressive can deal with anything container-interop. In practice it does not because of one reason: Expressive uses class name like identifiers with "" characters to access the services. Since Disco uses the given identifier to call a method on a config class this does not work as methods cannot contain the "" character.
Long story short: I think we need to define a valid range of characters for the $id parameter that can be passed to the get() and has() methods.
To be honest to me it sounds like a bug/a limitation of the implementation: Symfony for example strips those characters to have valid method names IIRC. It's similar to cache keys: using namespaces is very common, cache implementations will usually strip/convert/encode problematic characters when using the key as a file name.
Additionally forbidding to use \ will be a show-stopper for a lot of containers. The fact that there are no restrictions on services IDs is not an oversight, it's a feature.
The point I want to make is different: The current spec does not point out which characters are valid. Since Disco implements the container-interop interface it is per-se a valid implementation. But as I tried to point out currently not a valid drop-in replacement due to some "edge-cases" not covered. I am just saying we should make things clearer in the spec, either by limiting the valid characters or by saying the container needs to be able to deal with any kind of character set.
or by saying the container needs to be able to deal with any kind of character set.
OK I see. Right now there are no restriction (it's just a string), but more documentation can't hurt I guess.
Don't think that a restriction would be sane. If a restriction is needed
(valid reasoning to be provided), then we'd stop accepting string for
service names, and instead pass in an object that encapsulates the
limitation.
On 13 Aug 2016 19:01, "Matthieu Napoli" notifications@github.com wrote:
OK I see. Right now there are no restriction (it's just a string), but
more documentation can't hurt I guess.—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#84 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakFvm61cQmEDZKvbpnhTicRbXr4Ehks5qffhLgaJpZM4JjpZB
.
How to proceed?
IMO, the interface is clear: arbitrary strings must be allowed, including
empty string.
On 15 Aug 2016 13:26, "Stephan Hochdörfer" notifications@github.com wrote:
How to proceed?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#84 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAJakH_jB2csl6_c65eQ6jNvXZlfEAN9ks5qgEzggaJpZM4JjpZB
.
arbitrary strings must be allowed, including empty string.
Agreed, @shochdoerfer if you want to send a pull request to make that more explicit in the docs feel free.
Restricting the use of \ is clearly a huge BC break and a very limiting constraint that will render many containers incompatible, and for no gain.
Will think about it. Thanks guys.
@shochdoerfer : On a complete side-node, you could add an optional "name" argument to your @bean annotation to change the exposed name of the container entry. That would let your users use any entry name possible.
@moufmouf I actually decided against this because I did not want to deal with naming collisions. That's also the reason why I did not implement an alias feature.