August'24: Kamaelia is in maintenance mode and will recieve periodic updates, about twice a year, primarily targeted around Python 3 and ecosystem compatibility. PRs are always welcome. Latest Release: 1.14.32 (2024/3/24)
4 Simple Component - Microprocesses with standard external interfaces
Exercise: Write a class called component that subclasses microprocess with the following...
Attributes:
self.boxes - this should be a dictionary of the following form:
Clearly this allows for more inboxes and outboxes, but at this stage we'll keep things simple.
Behaviour: (methods)
As before an __init__ for
anything you need (eg attributes above :)
send(self, value, boxname)
This method takes the value and appends it to the end of the list associated with the boxname.
That is if I do:
Then given the suggested implementation of boxes above the following should be true afterwards:
ie the last value in the list associated with the boxname is the value we sent to that outbox. More explicitly, if the value of self.boxes was this beforehand:
And the following call had been made:
The self.boxes would look like this afterwards:
recv(self, boxname)
This is the logical opposite of sending. Rather than appending a value at the end of the send queue, we take the first value in the queue.
Behaviourally, given a starting value of self.boxes:
Then I would expect the following behaviour code.…
... to display the following sort of behaviour:
The value of self.boxes should also change as follows after each call:
dataReady(self, boxname)
This should return the length of the list associated with the
boxname.
For example, given:
The following behaviour is expected:
Answer:
Discussion:
Ok that's a fairly long description, but a fairly simple implementation. So what's this done? It's enabled us to send data to a running generator and receive data back. We're not worried what the generator is doing at any point in time, and so the communications between us and the generator (or between generators) is asynchronous.
An extension to the suggested __init__ is to do the following:
This small extension means that classes subclassing component can have a different set of inboxes and outboxes. For example:
That said, components by themselves are relatively boring. Unless we have some way of moving the data between generators we haven't gained anything (really) beyond the printer example above. So we need someone/something that can move data/messages from outboxes and deliver to inboxes...