Revision 409239bb5a645a495efece2b2ee65448d05a7565 authored by James Graham on 08 February 2018, 20:50:41 UTC, committed by Geoffrey Sneddon on 15 March 2018, 15:09:43 UTC
The goal here is to make it possible for different implemenations to implement defined subsets of the Protocol object, but require each subset to match a specific base class so it's clear when you have implemented all the pieces of a specific subset. The code here uses a sort of composition rather than inheritance. Multiple inheritance tends to be rather confusing, so instead we do something similar but slihgtly more explicit; assigning each ProtocolPart to an attibute of the Protocol so that the methods on a part with name foo are available as protocol.foo.method. This involves some changes to the lifecycle methods. In particular setup() is now split into connect() and after_connect() that are expected to be implemented in base classes. Between these being called we call setup() on each ProtocolPart so that we may give them direct access to a connection object or similar.
1 parent f808348
Computing file changes ...