I think #2 is pretty reasonable.
Jan Dolecek wrote: > 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 >>
