Sorry for the super-slow response, not sure if this ever got replied to. This was never implemented to avoid the implementation complexity it would introduce into languages that don't support multiple inheritance, and because there were decent alternate solutions for most of the problems it would solve. It is true that Thrift services are just interfaces. However, we do end up generating some base classes for services (such as the method dispatch handlers, etc.) With single-inheritance, it is quite straightforward to compose services in a single-inheritance chain, and there are clear semantics for what to do with method-name collisions (child class goes first, fall back to parent class).
It would definitely be possible to get multiple service inheritance working, but the implementation would likely require some code duplication or tricky object compositions in languages that don't support multiple inheritance or things like mixins. It could all be done, it's just a question of trading off complexity/maintenance/testing/etc. vs. the added utility of the feature. I think the feature that most people actually want here is not multiple inheritance, but rather the ability to run multiple Thrift services into one TServer engine. I think it's rare that people actually want to compose the service implementations into a single multiply-inherited class. Rather, they just don't want to have to run 3 services on 3 different ports. The big issue to navigate there is just the method dispatching -- how do you decide which method maps to which service, and what do you do if two services have a collision on a method name. If a simple rule was put in place that multiply-embedded services may not have ANY method name collisions, doing that would be quite straightforward (just have each service export a map of string => method callback, and then merge the map for all services). To support method-name collisions would likely require introducing something like a service identifier into the protocol. Cheers, mcslee -----Original Message----- From: Jan Dolecek [mailto:juzna...@gmail.com] Sent: Tuesday, May 11, 2010 8:39 AM To: thrift-dev Subject: Q: multiple inharitance of services I wonder, why Thrift _not_ supports multiple inharitance of services. I mean, services as defined by thrift are just interfaces and it's common practice in many programming languages, that class can implement more than one interface. Why is this not possible with thrift? Thanks for info Jan Dolecek juzna...@gmail.com
