I agree with Thomas on the naming issue. As far as I know it should not be a problem to implement that using mixins.
-- Janus Den 31/01/2008 kl. 11.01 skrev Thomas Jakobsen: > Hi > > I'm not sure I understand completely the distinction between multiple > inheritance and mix-ins. I guess I'd better go read a couple of pages > in Learning Python before I say anything. > > But in my opinion, an important issue is encapsulation of protocol > implementations. I think a typical user of the runtime would prefer to > simply invoke compare() on the runtime rather than, say, > compareToft05() or compareToft07(). By typical user I mean e.g. a > compiler or a programmer that is developing a higher-level > application. Will the mix-in approach allow the runtime to hide the > actual implementation of a protocol like comparison? Perhaps except in > a single place, where the user tells the runtime what protocols to > use. > > If not, we would have problems like this: A programmer implements some > large application, say, a quadro-auction, involving thousands of lines > of code with calls to compareToft07(). Then Tomas Toft happens to > invent an even faster comparison, compareToft08() ... which I guess is > not unlikely ;). The programmer will then have to rewrite his > application, changing all calls to compareToft07() to compareToft08() > in order to use the fastest available comparison. > > Best regards, > Thomas > > > On Jan 31, 2008 4:54 PM, Janus Dam Nielsen <[EMAIL PROTECTED]> wrote: >> Hi Martin, >> >> I am not so confident with the code base that I can judge which >> methods goes into which classes. So I am just going to tell you about >> cohesion. In OO programming one should strive to achieve as high a >> degree of cohesion for each class as possible. That is each class >> should serve ONE specialized and well defined purpose. Hence I think >> it would be great to split the Runtime class into multiple pieces. >> >> Mixins are the think you would want to use in the case of your >> comparisons, since it is not something which is only well defined for >> one protocol, but a given comparison make sense for multiple >> protocols. >> >> -- >> Janus >> >> >> Den 31/01/2008 kl. 4.40 skrev Martin Geisler: >> >> >>> Hello, >>> >>> I have thought a little about how we can split the current Runtime >>> class into smaller pieces. Currently runtime.py contains five >>> classes >>> and the Runtime class contains 26 methods. That is too much >>> information in one file. I think we can group the methods like this: >>> >>> Basic infrastructure: These methods are not specialized to deal with >>> crypto as such, they simply provide a means for players to talk >>> with >>> each other: >>> >>> * __init__ >>> * add_player >>> * shutdown >>> * wait_for >>> * synchronize >>> * callback >>> * _exchange_shares >>> >>> Protocols for passive security. This includes Shamir sharing, PRSS, >>> and opening of such shares: >>> >>> * shamir_share >>> * _shamir_share >>> * _recombine >>> * prss_share >>> * prss_share_random >>> * open >>> >>> We also have the basic protocols for doing arithmetic with shares: >>> >>> * add >>> * sub >>> * mul >>> * xor_int >>> * xor_bit >>> >>> Then comes the comparison protocol from Tomas' progress report, also >>> knows as the SCET comparison protocol: >>> >>> * greater_than >>> * _finish_greater_than >>> * _diamond >>> * convert_bit_share >>> >>> The final group would be the newer comparison protocol, also by >>> Tomas: >>> >>> * greater_thanII >>> * greater_thanII_preproc >>> * greater_thanII_online >>> * _finish_greater_thanII >>> * convert_bit_share_II >>> >>> >>> I propose that we split the Runtime class into these classes: >>> >>> * BaseRuntime containing common code needed by all runtimes. >>> >>> * PassiveRuntime inheriting from BaseRuntime with the standard >>> Shamir-based protocols. >>> >>> The comparison protocols could live in their own classes, maybe >>> named >>> >>> * ComparisonToft05Runtime >>> * ComparisonToft07Runtime >>> >>> for a lack of better names. These classes would not inherit from >>> PassiveRuntime since they can also be used with a runtime that >>> provides protocols for active security. >>> >>> So they could be made as mix-in classes instead. That is a class >>> that >>> you inherit from if you needs its functionality, please see >>> http://en.wikipedia.org/wiki/Mixin for some background. >>> >>> A combined runtime class could then be made as >>> >>> class Combined(PassiveRuntime, ComparisonToft05Runtime): pass >>> >>> or >>> >>> class Combined(PassiveRuntime, ComparisonToft07Runtime): pass >>> >>> depending on your need. The comparison protocol would be present >>> in a >>> greater_than method in both cases. When we have an ActiveRuntime >>> class, then programs may define their runtime class as >>> >>> class Combined(ActiveRuntime, ComparisonToft07Runtime): pass >>> >>> >>> I guess none of us is used to mixin classes, but the advantage as I >>> see it is that we avoid the problem of "blessing" one particular >>> protocol as the "right" one. We could of course also make the >>> inheritance hierarchy so that there is a ComparisonRuntime class >>> that >>> inherits from PassiveRuntime and implements a particular comparison >>> protocol. But then how would we easily reuse that code for the >>> active >>> case? A simple dot graph showing that I mean in the case where we >>> use >>> normal inheritance: >>> >>> <inheritance.png> >>> And another graph showing the mixins: >>> >>> <mixin.png> >>> Here the lower four classes would esentially be empty containing >>> only >>> a pass statement like the examples above. >>> >>> -- >>> Martin Geisler >>> _______________________________________________ >>> viff-devel mailing list (http://viff.dk/) >>> viff-devel@viff.dk >>> http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk >> >> _______________________________________________ >> viff-devel mailing list (http://viff.dk/) >> viff-devel@viff.dk >> http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk >> > _______________________________________________ > viff-devel mailing list (http://viff.dk/) > viff-devel@viff.dk > http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk _______________________________________________ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
