On 22.03.2010, at 16:35, Nils Adermann wrote: > I agree that type hinting actual implementations, read classes, is a > bad > idea. But I fail to see why having an interface definition for each > service is a bad idea. Even without type hinting every service > implementation will have to follow an implicit interface convention > anyway, otherwise you wouldn't be able to replace the service with a > different one at all. So if you develop a new service you will need to > implement this implicit interface, so why not make it explicit? > > You mention having to extend classes to be able to add the service > interface. I assume you are talking about classes that already exist > which you want to make available as services. Now with those classes, > isn't it pure luck if they already implement the implicit interface - > meaning they already have the right method signatures? Typically you > would either have to extend them or add proxies to delegate calls to > make sure the right method signatures are exposed. Such subclass or > proxies could again explicitly implement the interface easily.
You are of course right. I also thought about this and came to the conclusion that it really depends on the service. Like many caching layers have pretty much exactly the same API. In some cases you might be only using a limited set of methods. But that also means that your dependency is a bit fragile I guess. So yes I can totally see myself making frequent use of interfaces to be able to type hint, but I am not sure if we should make this a must use feature in order to get the injection to work. Not even sure if it should be natively supported as an option. But just to make my response clear: Yes in most cases you will probably need to stick some wrapper/proxy in front of the third party anyways and then you might as well also add the "implements [service name]" and having an interface around for each interface is also a nice piece of documentation for people wondering what they need to implement to be able to replace a service and for people who want to check on what they can rely on that is provided by the service. Documentation through code is always a good thing. regards, Lukas Kahwe Smith [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 To unsubscribe from this group, send email to symfony-devs+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
