On 3/31/11 5:44 PM, Jeremy Mikola wrote:
I'm +1 here. Given recent decisions to start using @api annotations throughout Symfony2, to denote stable API, having a collection of such interfaces makes that task even simpler IMO. This also goes along with our decision a month or two ago that more interfaces should be added throughout the codebase. Consolidating them into a single area would only reduce inter-component dependencies (if everything simply depended at least on the API namespace for interfaces).
I don't want to move all interfaces under API, just the ones that make sense for interoperability.
Fabien
On Thu, Mar 31, 2011 at 10:51 AM, Fabien Potencier <[email protected] <mailto:[email protected]>> wrote: We currently have a discussion about translation messages. Keys or English sentences? Everybody agree that keys are better, but English messages are best to keep components decoupled. Is there any solution? Read on. One of them is the introduction of the Symfony API. I've created a branch for that here: https://github.com/fabpot/symfony/tree/api and the relevant commit: https://github.com/fabpot/symfony/commit/45be152c33546affa4f1de4920ca14b0a0351620 Don't try it at home as it does not work (I have just moved files around to have a feeling for the result). Here is the commit message: added an API sub-namespace What's that? Symfony2 Components are standalone libraries that can be used without any external dependencies. But sometimes, you want optional dependencies. For instance, the Form component supports Twig but if you don't use Twig, there is no problem. Unfortunately, if the optional dependency is at the center of the component, it's a bit more tricky. The Form/Validator components provide error messages. Right now, they are defined as English strings, but some want to convert them to keys. If we use keys, we always need some kind of "translation" mechanism. But we don't want to force people to use the Translation component. So, you must provide a simple/fake implementation if the developer does not need translation. But that's not possible. You can create a local interface with a local implementation; but the external dependency won't extend your local interface. You are out of luck. That's where the Symfony2 API comes in. The Symfony2 API is a set of public interfaces that keeps the components decoupled but also allows for more optional features to be added. For the example above, the Form/Validator components can just use the Translator interface and provide a simple implementation locally. If the developer wants to internationalize his error messages, he can use the Symfony2 Translation component or any library that use the Symfony2 API. So, besides being a nice way to solve the Symfony2 components dependencies problem, it also exposes a nice API that others can implement to make their library interoperable with the Symfony2 ecosystem. The value of the Symfony2 API lies in the quality of the interfaces we publish and the fact that we keep their numbers as low as possible (for instance, do we need the DataCollector interface there? -- probably not). The Symfony2 API namespace structure does not necessarily follow the Component one (Logger for instance does not exist as a component). I have collected interfaces that I think should be in this API, but more can be added. Unfortunately, some components are not ready yet for that (for instance, the ValidatorInterface relies on Constraint objects, but there is not interface for them). Publishing the Symfony2 API will also force us to think more about our interfaces (see ValidatorInterface), outside of a Symfony2 context. Fabien -- Fabien Potencier Sensio CEO - Symfony lead developer sensiolabs.com <http://sensiolabs.com> | symfony.com <http://symfony.com> | fabien.potencier.org <http://fabien.potencier.org> Tél: +33 1 40 99 80 80 <tel:%2B33%201%2040%2099%2080%2080> -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com <http://symfony-project.com> You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] <mailto:[email protected]> To unsubscribe from this group, send email to [email protected] <mailto:symfony-devs%[email protected]> For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -- jeremy mikola -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
-- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
