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).
On Thu, Mar 31, 2011 at 10:51 AM, Fabien Potencier < [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 | symfony.com | fabien.potencier.org > Tél: +33 1 40 99 80 80 > > -- > 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 > -- 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
