Extracted the API of the Translation component into symfony/api #6189
Conversation
|
I still see an issue if we use a single package with the whole API: a package depending on the public interface of the Translation component would then dpeend on |
|
@stof First I thought the same. But in reality, if a package is only coupled to the interface, it does not depend on one specific implementation. We can take various approaches in this situation (even all of them):
What you are pointing out is only relevant for people that use the components stand-alone. 1. allows these people to not even load the second component, if not needed. 2. tells them which implementation they may use, but leaves them the choice. |
|
@bschussek Indeed it does not depend on a particular implementation. But it may require getting one implementation (it can be a required dependency to an interface). And you would still need to know which part of the API is used. Actually, the way PHPCR uses the composer features is the best way to make composer handle most of the work: {
"name": "symfony/translation-api"
}{
"name": "symfony/translation",
"require": {
"symfony/translation-api": "2.2.*"
},
"provide": {
"symfony/translation-implementation": "self.version"
}
}{
"name": "behat/behat",
"require": {
"symfony/translation-implementation": "2.2.*"
}
}And then, another package providing a implementation of the translation api would mark it provides the |
|
actually, we can even achieve it with a single |
|
Closing this PR as I think we have enough on our plate for the 2.x series. This should be something we might revisit for Symfony 3. |
Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: partially #6129
Todo: -
License of the code: MIT
Documentation PR: TODO
This PR implements the change suggested in #6129 for the Translation component. I think we should apply this change component by component so that we don't end up with one massive PR.