April 2024 - This site, and Kamaelia are being updated. There is significant work needed, and PRs are welcome.

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 Hidden

Show Answer

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...