Or it could be something like include, but inside of a service definition. Now I'm implementing some services which would be great to split into several small files and then include them into one big service provided by one handler. Now I gotta Copy&Paste the definitions, which is very unflexible.
My problem is communication with network devices, access points and some servers, so I've prepared services: - Diagnostics (functions ping, arping, traceroute....) - Blocking (blockIP, unblockIP.....) - Device info (getSysName, getIPAddressList,.....) - SNMP (activateSNMP, deactivateSNMP, setCommunity) - .... several others Now, when looking at concrete devices: - first one supports diagnostics, blocking, device info, but not SNMP. I was thinking about devining service myDevice1 with apropriate sub-services. - another one supports just device info - third supports all but blocking... My ideas are: 1/ service, which could extend more services in thrift file. No name collisions are allowed. When generating classes for concrete languages, thrift could do the copy&paste of all required methods. Therefore, language not needs multiple inharitance. 2/ include for services - in thrift file, i'll use sth. like include inside of service definition. No inharitance will be done. Thrift will just copy all functions from included service and paste them into the including one. What do you think about this? Or do you have some other solution to my problem? Thanks for info Jan Dolecek juzna...@gmail.com On Fri, May 21, 2010 at 2:53 AM, Mark Slee <ms...@facebook.com> wrote: > 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 >
