Clean interfaces, frozen and maintained bring complexity? I am not following...
I think the change is for the best and will allow end users to completely replace part of the framework or interacting components. +1 On Thu, Mar 31, 2011 at 11:04 AM, Mamady <[email protected]> wrote: > I smell bloatware. > > Although having an API sounds like a great idea, it may be too much > complexity, for too little a gain. Symfony2 has already taken leaps > toward massive complexity - for the sake of "flexibility". > > Making symfony so complex means that it becomes unsuitable for 95% of > projects. > > > > Mamady > > > On Mar 31, 2:51 pm, Fabien Potencier <fabien.potenc...@symfony- > project.com> 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/45be152c33546affa4f1de4920ca... > > > > 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 > -- *Bulat Shakirzyanov* | Software Alchemist *a: *about.me/avalanche123 *e:* [email protected] -- 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
