Interface Design Notes

Defects of the current design of interfaces and modules:

• Cannot import a given module twice
• Interface names aren't scoped (#49)
• Need to explicitly include Anise for the "declare" decorator (#59)
  • Easiest fix is to have a root BudModule/BudProtocol/etc. module that includes Anise and defines "declare"
• "state" blocks in an interface need to explicitly call "super"
  • Possible fix: replace "def state" with a "state { ... }"; state is a method defined by BudModule
• No clear distinction between importing a module for use as a client vs. importing an interface to provide an implementation of it
• Should temporal properties be exposed as part of an interface's API?
• Constraints on interfaces?

Use Cases for Modules

###Abstract interface, multiple concrete implementations

• Participants: client program P, abstract interface A, concrete implementations B and C
• P wants to use the functionality provided by A, but doesn't particularly care which implementation of A it uses
• Example: P is a program that wants to unicast messages to a remote host. A is an abstract DeliveryProtocol, and B and C are concrete delivery protocols (TCP-based and UDP-based, say).

###Composition of interface implementations

• Participants: abstract interface A, concrete implementations B and C.
• B implements A; C also implements A, but wants to reuse some of the machinery provided by B.
• Example: A is DeliveryProtocol, B is UnreliableDeliveryImpl, and C is ReliableDeliveryProtocol. We can implement reliable delivery on top of unreliable delivery + additional ACK messages.

###Multiple instanciation of a single module

• Participants: client program P, module A.
• P would like to use two different instances of A for different purposes
  • Q: When is this actually necessary? There are circumstances in which a single instance of a module can be used for two unrelated purposes simultaneously (e.g., a DeliveryProtocol can be used to send messages to different hosts concurrently).
  • A: The answer has something to do with whether there is shared state among different clients of a single module. Consider the case of a queue module: if we want to use the module to represent two logically-distinct queues, we can do that by adding a "queue id", and grouping on the queue ID.
  • Conclusion: (?) Multiple inclusion is not necessary for expressiveness, but might be useful syntax sugar.