Automatic Activation and Dependencies

You'll notice that each time we change an attribute value, our Rectangle instance above prints itself -- including when the instance is first created. That's because of two important Trellis principles:

1. When a Component instance is created, all its "non-optional" cell attributes are calculated after initialization is finished. That is, if the attribute is a maintenance or performing rule, and has not been marked optional, then the rule is invoked, and the result is used to determine the cell's initial value.
2. While a cell's rule is running, any trellis cell whose value is looked at becomes a dependency of that rule. If the looked-at cell changes later, it triggers recalculation of the rule that "looked". In Trellis terms, we say that the first cell has become a "listener" of the second cell.

The first of these principles explains why the rectangle printed itself immediately: the show performer cell was activated. We can see this if we look at the rectangle's show attribute:

>>> print r.show
None

(The show rule is a performer, so the resulting attribute value is None. Also notice that rules are not methods -- they are more like properties.)

The second principle explains why the rectangle re-prints itself any time one of the attributes changes value: all six attributes are referenced by the __repr__ method, which is called when the show performer prints the rectangle. Since the cells that store those attributes are being looked at during the execution of another cell's rule, they become dependencies, and the show rule is thus re-run whenever the listened-to cells change.

Each time a rule runs, its dependencies are automatically re-calculated -- which means that if you have more complex rules, they can actually depend on different cells every time they're calculated. That way, the rule is only re-run when it's absolutely necessary.

By the way, a listened-to cell has to actually change its value (as determined by the != operator), in order to trigger recalculation. Merely setting a cell doesn't cause its observers to recalculate:

>>> r.width = 17    # doesn't trigger ``show``

But changing it to a non-equal value does:

>>> r.width = 18
Rectangle((25, 0), (18, 10), (43, 10))

"Optional" Rules and Subclassing

The show rule we've been playing with on our Rectangle class is kind of handy for debugging, but it's kind of annoying when you don't need it. Let's turn it into an "optional" performer, so that it won't run unless we ask it to:

>>> class QuietRectangle(Rectangle):
...     @trellis.perform(optional=True)
...     def show(self):
...         print self

By subclassing Rectangle, we inherit all of its cell attribute definitions. We call our new optional rule show so that its definition overrides the noisy version of the rule. And, because it's marked optional, it isn't automatically activated when the instance is created. So we don't get any announcements when we create an instance or change its values:

>>> q = QuietRectangle(width=18, left=25)
>>> q.width = 17

Unless, of course, we activate the show rule ourselves:

>>> q.show
Rectangle((25, 0), (17, 30), (42, 30))

And from now on, it'll be just as chatty as the previous rectangle object:

>>> q.left = 0
Rectangle((0, 0), (17, 30), (17, 30))

While any other QuietRectangle objects we create will of course remain silent, since we haven't activated their show cells:

>>> q2 = QuietRectangle()
>>> q2.top = 99

@compute rules are always "optional". make() attributes are optional by default, but can be made non-optional by passing in optional=False. @maintain and @perform are non-optional by default, but can be made optional using optional=True.

Notice, by the way, that rule attributes are more like properties than methods, which means you can't use super() to call the inherited version of a rule. (Later, we'll look at other ways to access rule definitions.)

Read-Only and Read-Write Attributes

Attributes can vary as to whether they're settable:

• Passive values (attr(), attrs()) and @maintain rules are always settable
• make() attributes are settable only if created with writable=True
• @compute and @perform attributes are never settable

For example, here's a class with a non-settable aDict attribute:

>>> class Demo(trellis.Component):
...     aDict = trellis.make(dict)

>>> d = Demo()
>>> d.aDict
{}
>>> d.aDict[1] = 2
>>> d.aDict
{1: 2}

>>> d.aDict = {}
Traceback (most recent call last):
  ...
AttributeError: Constants can't be changed

Note, however, that even if an attribute isn't settable, you can still initialize the attribute value, before the attribute's cell is created:

>>> d = Demo(aDict={3:4})
>>> d.aDict
{3: 4}

>>> d = Demo()
>>> d.aDict = {1:2}
>>> d.aDict
{1: 2}

Since the aDict attribute is "optional" (make attributes are optional by default), it wasn't initialized when the Demo instance was created. So we were able to set an alternate initialization value. But, if we make it non-optional, we can't do this, because the attribute will be initialized during instance construction:

>>> class Demo(trellis.Component):
...     aDict = trellis.make(dict, optional=False)

>>> d = Demo()
>>> d.aDict = {1:2}
Traceback (most recent call last):
  ...
AttributeError: Constants can't be changed

And so, non-optional read-only attributes can only be set while an instance is being created:

>>> d = Demo(aDict={3:4})
>>> d.aDict
{3: 4}

But if an attribute is settable, it can be set at any time, whether the attribute is optional or not:

>>> class Demo(trellis.Component):
...     aDict = trellis.make(dict, writable=True)

>>> d = Demo()
>>> d.aDict = {1:2}
>>> d.aDict = {3:4}

Model-View-Controller and the "Observer" Pattern

As you can imagine, the ability to create rules like this can come in handy for debugging. Heck, there's no reason you have to print the values, either. If you're making a GUI application, you can define rules that update displayed fields to match application object values.

For that matter, you don't even need to define the rule in the same class! For example:

>>> class Viewer(trellis.Component):
...     model = trellis.attr(None)
...
...     @trellis.perform
...     def view_it(self):
...         if self.model is not None:
...             print self.model

>>> view = Viewer(model=q2)
Rectangle((0, 99), (20, 30), (20, 129))

Now, any time we change q2, it will be printed by the Viewer's view_it rule, even though we haven't activated q2's show rule:

>>> q2.left = 66
Rectangle((66, 99), (20, 30), (86, 129))

This means that we can automatically update a GUI (or whatever else might need updating), without adding any code to the thing we want to "observe". Just use cell attributes, and everything can use the "observer pattern" or be a "Model-View-Controller" architecture. Just define rules that can read from the "model", and they'll automatically be invoked when there are any changes to "view".

Notice, by the way, that our Viewer object can be repointed to any object we want. For example:

>>> q3 = QuietRectangle()
>>> view.model = q3
Rectangle((0, 0), (20, 30), (20, 30))

>>> q2.width = 59       # it's not watching us any more, so no output

>>> view.model = q2     # watching q2 again
Rectangle((66, 99), (59, 30), (125, 129))

>>> q3.top = 77         # but we're not watching q3 any more

See how each time we change the model attribute, the view_it rule is recalculated? The rule references self.model, which is a value cell attribute. So if you change view.model, this triggers a recalculation, too.

Remember: once a rule reads another cell, it will be recalculated whenever the previously-read value changes. Each time view_it is invoked, it renews its dependency on self.model, but also acquires new dependencies on whatever the repr() of self.model looks at. Meanwhile, any dependencies on the attributes of the previous self.model are dropped, so changing them doesn't cause the perform rule to be re-invoked any more. This means we can even do things like set model to a non-component object, like this:

>>> view.model = {}
{}

But since dictionaries don't use any cells, changing the dictionary won't do anything:

>>> view.model[1] = 2

To be able to observe mutable data structures, you need to use data types like trellis.Dict and trellis.List instead of the built-in Python types. We'll cover how that works in the section below on Mutable Data Structures.

By the way, the links from a cell to its listeners are defined using weak references. This means that views (and cells or components in general) can be garbage collected even if they have dependencies. For more information about how Trellis objects are garbage collected, see the later section on Garbage Collection.

Accessing a Rule's Previous Value

Sometimes it's useful to create a maintained value that's based in part on its previous value. For example, a rule that produces an average over time, or that ignores "noise" in an input value, by only returning a new value when the input changes more than a certain threshhold since the last value. It's fairly easy to do this, using a @maintain rule that refers to its previous value:

>>> class NoiseFilter(trellis.Component):
...     trellis.attrs(
...         value = 0,
...         threshhold = 5,
...     )
...     @trellis.maintain(initially=0)
...     def filtered(self):
...         if abs(self.value - self.filtered) > self.threshhold:
...             return self.value
...         return self.filtered

>>> nf = NoiseFilter()
>>> nf.filtered
0
>>> nf.value = 1
>>> nf.filtered
0
>>> nf.value = 6
>>> nf.filtered
6
>>> nf.value = 2
>>> nf.filtered
6
>>> nf.value = 10
>>> nf.filtered
6
>>> nf.threshhold = 3   # changing the threshhold re-runs the filter...
>>> nf.filtered
10
>>> nf.value = -3
>>> nf.filtered
-3

As you can see, referring to the value of a cell from inside the rule that computes the value of that cell, will return the previous value of the cell. (Note: this is only possible in @maintain rules.)

Beyond The Spreadsheet: "Resetting" Cells

So far, all the stuff we've been doing isn't really any different than what you can do with a spreadsheet, except maybe in degree. Spreadsheets usually don't allow the sort of circular calculations we've been doing, but that's not really too big of a leap.

But practical programs often need to do more than just reflect the values of things. They need to do things, too.

So far, we've seen only attributes that reflect a current "state" of things. But attributes can also represent things that are "happening", by automatically resetting to some sort of null or default value. In this way, you can use an attribute's value as a trigger to cause some action, following which it resets to an "empty" or "inactive" value. And this can then help us handle the "Controller" part of "Model-View-Controller".

For example, suppose we want to have a controller that lets you change the size of a rectangle. We can use "resetting" attributes to do this, in a way similar to an "event", "message", or "command" in a GUI or other event-driven system:

>>> class ChangeableRectangle(QuietRectangle):
...     trellis.attrs.resetting_to(
...         wider    = 0,
...         narrower = 0,
...         taller   = 0,
...         shorter  = 0
...     )
...     width = trellis.maintain(
...         lambda self: self.width  + self.wider - self.narrower,
...         initially = 20
...     )
...     height = trellis.maintain(
...         lambda self: self.height + self.taller - self.shorter,
...         initially = 30
...     )

>>> c = ChangeableRectangle()
>>> view.model = c
Rectangle((0, 0), (20, 30), (20, 30))

A resetting attribute (created with attr(resetting_to=value) or attrs.resetting_to()) works by receiving an input value, and then automatically resetting to its default value after its dependencies are updated. For example:

>>> c.wider
0

>>> c.wider = 1
Rectangle((0, 0), (21, 30), (21, 30))

>>> c.wider
0

>>> c.wider = 1
Rectangle((0, 0), (22, 30), (22, 30))

Notice that setting c.wider = 1 updated the rectangle as expected, but as soon as all updates were finished, the attribute reset to its default value of zero. In this way, every time you put a value into a resetting attribute, it gets processed and discarded. And each time you set it to a non-default value, it's treated as a change. Which means that any maintenance or performing rules that depends on the attribute will be recalculated (along with any @compute rules in between). If we'd used a normal trellis.attr here, and then set c.wider = 1 twice in a row, nothing would have happen the second time, because the value would not have changed.

Now, we could write methods for changing value cells that would do this sort of resetting for us, but it wouldn't be a good idea. We'd need to have both the attribute and the method, and we'd need to remember to never set the attribute directly. (What's more, it wouldn't even work correctly, for reasons we'll see later.) It's much easier to just use a resetting attribute as an "event sink" -- that is, to receive, consume, and dispose of any messages or commands you want to send to an object.

But why do we need such a thing at all? Why not just write code that directly manipulates the model's width and height? Well, sometimes you can, but it limits your ability to create generic views and controllers, makes it impossible to "subscribe" to an event from multiple places, and increases the likelihood that your program will have bugs -- especially order-dependency bugs.

If you use rules to compute values instead of writing code to manipulate values, then all the code that affects a value is in exactly one place. This makes it very easy to verify whether that code is correct, because the way the value is arrived at doesn't depend on what order a bunch of manipulation methods are being called in, and whether those methods are correctly updating everything they should.

Thus, as long as a cell's rule doesn't modify anything except local variables, there is no way for it to become "corrupt" or "out of sync" with the rest of the program. This is a form of something called "referential transparency", which roughly means "order independent". We'll cover this topic in more detail in the later section on Managing State Changes. But in the meantime, let's look at how using attributes instead of methods also helps us implement generic controllers.

Creating Generic Controllers by Sharing Cells

Let's create a couple of generic "Spinner" controllers, that take a pair of "increase" and "decrease" command attributes, and hook them up to our changeable rectangle:

>>> class Spinner(trellis.Component):
...     """Increase or decrease a value"""
...     increase = trellis.attr(resetting_to=0)
...     decrease = trellis.attr(resetting_to=0)
...     by = trellis.attr(1)
...
...     def up(self):
...         self.increase = self.by
...
...     def down(self):
...         self.decrease = self.by

>>> cells = trellis.Cells(c)
>>> width = Spinner(increase=cells['wider'], decrease=cells['narrower'])
>>> height =  Spinner(increase=cells['taller'], decrease=cells['shorter'])

The trellis.Cells() API returns a dictionary containing all active cells for the object. (We'll cover more about this in the section below on Working With Cell Objects_.) You can then access them directly, assigning them to other components' attributes.

Assigning a Cell object to a cell attribute allows two components to share the same cell. In this case, that means setting the .increase and .decrease attributes of our Spinner objects will set the corresponding attributes on the rectangle object, too:

>>> width.up()
Rectangle((0, 0), (23, 30), (23, 30))

>>> width.down()
Rectangle((0, 0), (22, 30), (22, 30))

>>> height.by = 5

>>> height.down()
Rectangle((0, 0), (22, 25), (22, 25))

>>> height.up()
Rectangle((0, 0), (22, 30), (22, 30))

Could you do the same thing with methods? Maybe. But can methods be linked the other way?:

>>> width2 = Spinner()
>>> height2 = Spinner()
>>> controlled_rectangle = ChangeableRectangle(
...     wider = trellis.Cells(width2)['increase'],
...     narrower = trellis.Cells(width2)['decrease'],
...     taller = trellis.Cells(height2)['increase'],
...     shorter = trellis.Cells(height2)['decrease'],
... )

>>> view.model = controlled_rectangle
Rectangle((0, 0), (20, 30), (20, 30))

>>> height2.by = 10
>>> height2.up()
Rectangle((0, 0), (20, 40), (20, 40))

A shared cell is a shared cell: it doesn't matter which "direction" you share it in! It's a simple way to create an automatic link between two parts of your program, usually between a view or controller and a model. For example, if you create a text editing widget for a GUI application, you can define a value cell for the text in its class:

>>> class TextEditor(trellis.Component):
...     text = trellis.attr('')
...
...     @trellis.perform
...     def display(self):
...         print "updating GUI to show", repr(self.text)

>>> te = TextEditor()
updating GUI to show ''

>>> te.text = 'blah'
updating GUI to show 'blah'

And then you'd write some additional code to automatically set self.text when there's accepted input from the GUI. An instance of this editor can then either maintain its own text cell, or be given a cell from an object whose attributes are being edited.

This allows you to independently test your models, views, and controllers, then simply link them together at runtime in any way that's useful.

Resetting Rules

Resetting attributes are designed to "accept" what might be called events, messages, or commands. But what if you want to generate or transform such events instead?

Let's look at an example. Suppose you'd like to trigger an action whenever a new high temperature is seen:

>>> class HighDetector(trellis.Component):
...     value = trellis.attr(0)
...     last_max = trellis.attr(None)
...
...     @trellis.maintain
...     def new_high(self):
...         last_max = self.last_max
...         if last_max is None:
...             self.last_max = self.value
...             return False    # first seen isn't a new high
...         elif self.value > last_max:
...             self.last_max = self.value
...             return True
...         return False
...
...     @trellis.perform
...     def monitor(self):
...         if self.new_high:
...             print "New high"

The new_high rule runs whenever value changes, and checks to see if it's greater than the current highest value. If so, it returns true and updates the maximum value. Let's try it out:

>>> hd = HighDetector()

>>> hd.value = 7
New high

>>> hd.value = 9

Oops! We set a new high value, but the monitor rule didn't detect a new high, because new_high was already True from the previous high.

Just as with a regular attribute, rules normally return what might be called "continuous" or "steady state" values. That is, their value remains the same until something causes them to be recalculated. In this case, the second recalculation of new_high returns True, just like the first one... meaning that there's no change, and thus the performing rule isn't triggered.

But, just as with regular attributes, @compute and @maintain rules can be made "resetting", using the resetting_to= keyword, allowing the value to reset to a default as soon as all of the value's listeners have "seen" the original value. Let's try a new version of our high detector:

>>> class HighDetector2(HighDetector):
...
...     @trellis.maintain(resetting_to=False)
...     def new_high(self):
...         # this is a bit like a super() call, but for a rule:
...         return HighDetector.new_high.rule(self)

>>> hd = HighDetector2()

>>> hd.value = 7
New high

>>> hd.value = 9
New high

>>> hd.value = 3

>>> hd.value = 16
New high

As you can see, each new high is detected correctly now, because the value of new_high is silently reset to False after it's calculated as (or set to) any other value:

>>> hd.new_high
False

>>> hd.new_high = True
New high

>>> hd.new_high
False

(By the way, that HighDetector.new_high.rule in the new new_high rule retrieves the base class version of the rule. We could also have done the same thing this way:

>>> class HighDetector2(HighDetector):
...     new_high = trellis.maintain(
...         HighDetector.new_high.rule, resetting_to = False
...     )

and the result would have been the same, except it would run faster since the lookup of the inherited rule only happens once.)

Wiring Up Multiple Components

Over the course of this tutorial, we've created a whole bunch of different objects, like the temperature converter, high detector, changeable rectangle, and a simple viewer. Let's link them up together to make a rectangle that gets wider and taller whenever the Celsius temperature reaches a new high:

>>> tc = TempConverter()
Celsius...... 0.0
Fahrenheit... 32.0

>>> hd = HighDetector2(value = trellis.Cells(tc)['C'])
>>> cr = ChangeableRectangle(
...     wider  = trellis.Cells(hd)['new_high'],
...     taller = trellis.Cells(hd)['new_high'],
... )

>>> viewer = Viewer(model = cr)
Rectangle((0, 0), (20, 30), (20, 30))

>>> tc.F = -40
Celsius...... -40.0
Fahrenheit... -40

>>> tc.F = 50
Celsius...... 10.0
Fahrenheit... 50
New high
Rectangle((0, 0), (21, 31), (21, 31))

Crazy, huh? None of these components were designed with any of the others in mind, but because they all "speak Trellis", you can link them up like building blocks to do new and imaginative things.

By the way, although in this demonstration we saw the three outputs in one particular order, in general the Trellis does not guarantee what order rules will be recalculated in, so it's unwise to assume that your program will always produce results in a certain order, unless you've taken steps to ensure that it will.

That's why managing the order of Trellis output (and dealing with state changes in general) is the subject of our next major section.

Modifiers

The Trellis actually does something similar, but its internal "event queue" is automatically flushed whenever you set a value from outside a rule. If you want to set multiple values, you need to use a @modifier function or method like this one, which we could've made a method of Rectangle, but didn't:

>>> @trellis.modifier
... def set_position(rectangle, left, top):
...     rectangle.left = left
...     rectangle.top = top

>>> set_position(r, 55, 22)
Rectangle((55, 22), (18, 10), (73, 32))

Notifications of changes made by a modifier do not take effect until the outermost active modifier function returns. (In other words, if one modifier directly or indirectly calls another modifier, the inner modifier's changes don't cause notifications to occur until the same time as the outer modifier's changes do.)

Now, notice that this means that within a modifier, you can't rely on any values controlled by rules to be updated when you make changes. This means it's generally a bad idea for a rule to look at what it's changing. For example:

>>> @trellis.modifier
... def set_position(rectangle, left, top):
...     rectangle.left = left
...     rectangle.top = top
...     print rectangle

>>> set_position(r, 22, 55)
Rectangle((22, 55), (18, 10), (73, 32))
Rectangle((22, 55), (18, 10), (40, 65))

The first print is from inside the rule, showing that from the rule's perspective, the bottom/right co-ordinates are not updated to reflect the changed top/left co-ordinates. The second print is from a perform rule, showing that the values do get updated after the modifier has exited.

The Evil of Order Dependency

The reason that time is the enemy of event driven programs is because time implies order, and order implies order dependency -- a major source of bugs in event-driven and GUI programs.

Writing a polished GUI program that has no visual glitches or behavioral quirks is difficult precisely because such things are the result of changes in the order that events occur in.

Worse still, the most seemingly-minor change to a previously working version of such a program can introduce a whole slew of new bugs, making it hard to predict how long it will take to implement new features. And as a program gets more complex, even fixing bugs can introduce new bugs!

Indeed, Adobe Systems Inc. estimates that nearly half of all their reported desktop application bugs (across all their applications!) are caused by such event-management problems.

So a major goal of the Trellis' is to not only wipe out these kinds of bugs, but to prevent most of them from happening in the first place.

And all you have to do to get the benefits, is to divide your code three ways:

• Input code, that sets trellis cells or calls modifier methods, but does not run inside trellis rules. This kind of code is usually invoked by GUI or other I/O callbacks, or by top-level non-trellis code.
• Processing rules that compute values, and/or make undo-able changes to cells or other data structures. (i.e. @compute and @maintain rules.)
• Output rules that send data on to other systems (like the screen, a socket, a database, etc.). This code may appear in @perform rules, or it can be "application" code that reads results from a finished trellis calculation.

The first and third kinds of code are inherently order-dependent, since information comes in (and must go out) in a meaningful order. However, by putting related outputs in the same performer (or non-trellis code), you can ensure that the required order is enforced by a single piece of code. This approach is highly bug-resistant.

Second, you can reduce the order dependency of input code by making it do as little as possible, simply dumping data into input cells, where it can be handled by processing rules. And, since input controllers can be very generic and highly-reusable, there's a natural limit to how much input code you will need.

By using these approaches, you can maximize the portion of your application that appears in side effect-free (or at least undo-able) processing rules, which the Trellis makes 100% immune to order dependencies. Anything that happens in Trellis rules, happens instantaneously, in a logical sense. Ther is no "order", and thus no order dependency.

In truth, of course, rules do execute in some order. However, as long as the rules don't do anything but compute their own values, then it cannot matter what order they do it in. (The trellis guarantees this by automatically recalculating rules whenever their dependencies change, and undoing any calculations that "saw" out-of-date or inconsistent values.)

The Side-Effect Rules

To sum up the recommended approach to handling side-effects in Trellis-based programs, here are a few brief guidelines that will keep your code easy to write, understand, and debug.

>>> class Conflict(trellis.Component):
...     value = trellis.attr(99)
...
...     @trellis.maintain
...     def ruleA(self):
...         self.value = 22
...
...     @trellis.maintain
...     def ruleB(self):
...         self.value = 33

>>> Conflict()
Traceback (most recent call last):
  ...
InputConflict: (33, 22)

>>> import sys

>>> class ChangeTakesTime(trellis.Component):
...     v1 = trellis.attr(2)
...     v2 = trellis.compute(lambda self: self.v1*2)
...     @trellis.maintain
...     def update(self):
...         if self.v1!=3:
...             print "before", self.v1, self.v2
...             self.v1 = 3
...             print "after", self.v1, self.v2

>>> x = ChangeTakesTime()
before 2 4
after 3 4

>>> x.v2
6

Mutable Data Structures

So far, all of our Trellis examples have worked with atomic cell values, like integers, strings, and so forth. We've avoided working with lists, sets, dictionaries, and similar structures, because the standard Python implementations of these types can't be "observed" by rules, which means that they won't be automatically updated.

But this doesn't mean you can't use sets, lists, and dictionaries. You just need to use Trellis-managed ones. (Of course, all the warnings above about changing values still apply; just because you're modifying something other than attributes, doesn't mean you're not still modifying things!)

The Trellis package provides three primary mutable types for you to use in your components: Set, List, and Dict. You can also subclass them or create your own mutable types, as we'll discuss in a later section. (And, the peak.events.collections module also provides some fancier data structures; see the Collections manual for details.)

>>> d = trellis.Dict(a=1)
>>> view.model = d
{'a': 1}

>>> del d['a']
{}

>>> d['a'] = 2
{'a': 2}

>>> d['a'] = 2
{'a': 2}

>>> view.model = None

>>> class Dumper(trellis.Component):
...     @trellis.perform
...     def dump(self):
...         for name in 'added', 'changed', 'deleted':
...             if getattr(d, name):
...                 print name, '=', getattr(d, name)
>>> dumper=Dumper()

>>> del d['a']
deleted = {'a': 2}

>>> d[3] = 4
added = {3: 4}

>>> d[3] = 5
changed = {3: 5}

>>> @trellis.modifier
... def two_at_once():
...     del d[3]
...     d[4] = 5

>>> two_at_once()
added = {4: 5}
deleted = {3: 5}

>>> d.added
{}

>>> d.setdefault(1, 2)
Traceback (most recent call last):
  ...
InputConflict: Can't read and write in the same operation

>>> s = trellis.Set("abc")
>>> view.model = s
Set(['a', 'c', 'b'])

>>> s.add('d')
Set(['a', 'c', 'b', 'd'])

>>> s.remove('c')
Set(['a', 'b', 'd'])

>>> s -= trellis.Set(['a', 'b'])
Set(['d'])

>>> view.model = None

>>> class Dumper(trellis.Component):
...     @trellis.perform
...     def dump(self):
...         for name in 'added', 'removed':
...             if getattr(s, name):
...                 print name, '=', list(getattr(s, name))
>>> dumper=Dumper()

>>> s.add('a')
added = ['a']

>>> s.add('a')      # duplicates are ignored

>>> s.remove('d')
removed = ['d']

>>> s.pop()
Traceback (most recent call last):
  ...
InputConflict: Can't read and write in the same operation

>>> myList = trellis.List([1,2,3])
>>> myList
[1, 2, 3]

>>> myList.reverse()    # no output while not being observed

>>> view.model = myList
[3, 2, 1]

>>> myList.reverse()    # but now we're being watched
[1, 2, 3]

>>> myList.insert(0, 4)
[4, 1, 2, 3]

>>> myList.sort()
[1, 2, 3, 4]

>>> myList.changed
False

>>> view.model = None   # quiet, please

>>> class Watcher(trellis.Component):
...     @trellis.perform
...     def dump(self):
...         print myList.changed

>>> watcher=Watcher()
False

>>> del myList[0]
True
False

>>> myList
[2, 3, 4]

>>> myList.pop()
Traceback (most recent call last):
  ...
InputConflict: Can't read and write in the same operation

trellis.Pipe

A trellis.Pipe is a little bit like a Python list, except it only has supports for 5 methods: append, extend, __iter__, __len__, and __contains__. Its purpose is to allow you to easily interconnect components that communicate streams of objects or data, not unlike an operating system pipe. You can use append() and extend() to put data in the pipe, and use the other methods to get it back out. And it resets itself to being empty after all of its observers have had a chance to see the contents:

>>> p = trellis.Pipe()

>>> view.model = p
[]

>>> p.append(42)
[42]
[]

>>> p.extend([27, 59])
[27, 59]
[]

One common use for pipes is to allow you to create objects that communicate via sockets or other IPC. If you write a component so that it expects to receive its inputs via one pipe, and sends output to another, then those pipes can be connected at runtime to a socket. And at test time, you can just append data to the input pipe, and have a performer spit out what gets written to the output pipe.

The Pipe type is the trellis's simplest data structure type -- so you may want to have a peek at its source code after you read the next section. (Better still, try to write your own Pipe clone first, and then compare it to the real one!)

Creating Your Own Data Structures

If you want to create your own data structures along the lines of Dict, List, and Set, you have a few options. First, you can just build components that use those existing data types, and use @modifier methods to perform operations on them. (If you just directly perform operations, then listeners of your data structure may be recalculated in the middle of your changes, and see an inconsistent state.)

Depending on the nature of the data structure you need, however, this may not be sufficient. For example, when you perform multiple operations on a trellis.Dict, the later operations need to know about changes made by the earlier ones. If you add some items and then delete one, for example, the dict needs to know whether the item you're deleting is one of the ones that you added.

But, if you use normal read operations on the dictionary (like .has_key()), these will only reflect the "before" state -- what the dictionary had in it during the current recalculation, before any new changes were made.

So, the Trellis-supplied data types use a couple of special tools to allow them to "see the future" (and change it).

Let's suppose that we're creating a simple "queue" type, that keeps track of items added to it. Its output is a list of the most-recently added items, and the list becomes empty in the next recalculation if nobody adds anything to it:

>>> class Queue(trellis.Component):
...     items = trellis.todo(list)
...     to_add = items.future
...
...     @trellis.modifier
...     def add(self, item):
...         self.to_add.append(item)
...
...     def __repr__(self):
...         return str(self.items)

>>> q = Queue()
>>> view.model = q
[]

>>> q.add(1)
[1]
[]

Let's break down the pieces here. First, we create a "todo" cell. A todo cell is basically a resetting_to attribute, except that it resets to a calculated value instead of a constant. It takes a function or type, just like make. That is, if you use a function (or other object with a __get__ method), it's called with the object the attribute belongs to, and if you use a type (or other object lacking a __get__ method), it's called with no arguments.

When the "todo" cell is created, the rule is called to create the resetting value, just as with a make attribute. Unlike a make attribute, however, its rule will be called again each time a "future" (i.e. modified) value is required.

(By the way, you can define todo cells with either a direct call as shown above, a @trellis.todo decorator on a function, or by using trellis.todos(attr=func, ...)` in your class body.)

The second thing that we did in this class above is create a "future" property. Todo cell descriptors have a .future attribute that returns a new property. (This property accesses the "future" version of the todo cell's value -- causing the rule to be called to generate a new value, and various undo-log operations to be performed.)

Next, we define a modifier method, add(). This method accesses the to_add attribute, thereby getting the future value of the items attribute. This future value is initially created by calling the "todo" cell's rule. In this case, the rule returns an empty list, so that's what add() sees, and adds a value to it.

(Note, by the way, that you cannot access future values except from inside a @modifier function.)

Next, let's create another @modifier that adds more than one item to the to_add attribute. This will works because only a single "future value" is created during a given recalculation sweep, and @modifier methods guarantee that no new sweeps can occur while they are running. Thus, the changes made in the modifier won't take effect until it returns:

>>> @trellis.modifier
... def add_many(*args):
...     for arg in args: q.add(arg)

>>> add_many(1,2,3)
[1, 2, 3]
[]

Finally, notice that after each change, the queue resets itself to empty, because the default value of the items cell is the empty list that was created when the cell was initialized.

Of course, since "todo" attributes are automatically resetting, what we've seen so far isn't enough to create a data structure that actually keeps any data around. To do that, we need to combine "todo" attributes with a rule to maintain an existing data structure:

>>> class Queue2(Queue):
...     added = trellis.todo(list)
...     to_add = added.future
...
...     @trellis.maintain(make=list)
...     def items(self):
...         if self.added:
...             return self.items + self.added
...         return self.items

>>> q = Queue2()
>>> view.model = q
[]

>>> q.add(1)
[1]

>>> add_many(2, 3, 4)
[1, 2, 3, 4]

This version is very similar to the first version, but it separates added from items, and the items rule is set up to compute a new value that includes the added items. (Notice also the use of the make keyword to initialize items to an empty list before the items rule is run for the first time.)

Notice, by the way, that the items rule returns a new list every time there is a change. If it didn't, the updates wouldn't be tracked:

>>> class Queue3(Queue2):
...     @trellis.maintain(make=list)
...     def items(self):
...         if self.added:
...             self.items.extend(self.added)
...         return self.items

>>> q = Queue3()
>>> view.model = q
[]

>>> q.add(1)

>>> add_many(2, 3, 4)

Why are no updates displayed here? Because items is being modified in-place, and when the trellis compares the "before" and "after" versions of its value, it concludes they are the same. This didn't happen when we returned a new list, because the old list still had its old contents, and the new list was different.

If you are modifying a return value in place like this, you should use the the trellis.mark_dirty() API to flag that your return value has changed, even though it's the same object. In addition, you should log an undo action so that if the trellis needs to roll back some calculations involving your data structure, it can do so:

>>> class Queue4(Queue2):
...     @trellis.maintain(make=list)
...     def items(self):
...         items = self.items
...         if self.added:
...             trellis.on_undo(items.__delitem__, slice(len(items),None))
...             items.extend(self.added)
...             trellis.mark_dirty()
...         return items

>>> q = Queue4()
>>> view.model = q
[]

>>> q.add(1)
[1]

>>> add_many(2, 3, 4)
[1, 2, 3, 4]

As you can see, calling mark_dirty() caused the trellis to notice the change to the list, even though the newly-returned list is (by definition) still equal to the previous value of the rule (i.e., the same list).

The on_undo() function lets you register a callback function (with optional positional arguments) that will be invoked if the trellis needs to roll back changes due to an error, or due to an out-of-order calculation. (If a rule makes a change to a data structure that has already been read by another rule, the trellis has to undo any changes made by the earlier rule and re-run it to ensure consistent results.)

Registered functions are called in reverse order, so that callbacks registered by later on_undo() calls will run before earlier ones. The Trellis keeps track of what callbacks were registered during each rule's execution, so that it can roll back the minimum number of changes needed to resolve a calculation order conflict. In the event of an error, however, all changes are rolled back:

>>> @trellis.modifier
... def error_demo():
...     @trellis.Performer   # make a standalone performing rule
...     def bad_observer():
...         print q
...         raise RuntimeError("ha!")
...     q.add(5)

>>> try: error_demo()
... except RuntimeError: print "caught error"
[1, 2, 3, 4, 5]
caught error

>>> print q
[1, 2, 3, 4]

This example is a bit odd, because it's somewhat difficult to force the trellis to get an error in such a way as to test your undo logging. If we had simply raised an error in the modifier, the change would appear to have been rolled back, when in fact it hadn't happened yet! (It's easy to see this if you add a "print" to the items rule -- if you raise an error in the modifier, it will never be called, because the rules don't run until the modifier is over.)

So to actually test the undo-ing, we have to raise the error in a new performer cell, which then runs after q.items is updated. (Performers don't run until/unless there are no other kinds of rules pending.)

In later sections on Working with Cell Objects, we'll see more about how to create and use one-off cells like this Performer, without needing to make them part of a component.

In the meantime, please note that creating good trellis data structures can be tricky: be sure to write automated tests for your code, and verify that they actually test what you think they test. This is one situation where it's REALLY a good idea to write your tests first, and try to make them fail before you add any mark_dirty() or on_undo() calls to your code. Otherwise, you won't be sure that your tests are really testing anything!

Of course, you don't need to deal with mark_dirty() and undo() at all, if you stick to using immutable values as a basis for your data structure, or use a copy-on-write approach like that shown in our Queue2 example above. Such data structures are less efficient than updating in-place, if they contain large amounts of data, but not every data structure needs to contain large quantities of data!

Therefore, we suggest that you start with simpler data structures first, and only add in-place updates if and when you can prove that the data copying is unacceptable overhead, since such updates are harder to write in a provably-correct way. (Note, too, that Python's built-in data types can often copy data a lot faster than you'd expect...)

A Practical Example -- and trellis.Pipe

Read-Only and Constant Cells

As you can see, you can provide either a value only, or a rule and a value when you create a cell. However, if you provide just a rule and no value, you end up with a read-only cell whose value can't be set:

>>> roc = trellis.Cell(lambda: 123)

>>> roc.value = 456
Traceback (most recent call last):
  ...
AttributeError: can't set attribute

In fact, it's not even a Cell instance, but of a different type altogether:

>>> roc
ReadOnlyCell(<function <lambda> at ...>, None [uninitialized])

What the above means is that you have a read-only cell whose current value is None, but has not yet been initialized. This means that if you actually try to read the value of this cell, it may or may not match what the repr() showed. (This is because simply looking at the cell shouldn't cause the cell's value to be calculated; that could be very painful when debugging).

If we actually read the value of this cell, the rule will be run:

>>> roc.value
123

But since the rule doesn't depend on any other cells, the cell changes type again, to a Constant:

>>> roc
Constant(123)

Since the rule didn't depend on any other cells, there is never any way that it could be meaningfully recalculated. Thus, it becomes constant, and cannot be listened-to by any other rules. If we create another rule that reads this cell, it will not end up depending on it:

>>> cell2 = trellis.Cell(lambda: roc.value)
>>> cell2.value
123

>>> cell2
Constant(123)

Thus, constant values propagate automatically through the cell network, eliminating dependencies on things that can't possibly change. Of course, if a read-only cell depends on a cell that can change, it remains a read-only cell, and will be recalculated whenever its dependencies change:

>>> c1 = trellis.Cell(value=0)
>>> c2 = trellis.Cell(lambda: c1.value * 2)

>>> c2.value
0
>>> c1.value = 27
>>> c2
ReadOnlyCell(<function <lambda>...>, 54)

Note that you can take advantage of constant propagation by explicitly setting a component attribute to a trellis.Constant at creation time. For example, if for some reason you wanted a temperature converter that could only be used once:

>>> tc = TempConverter(C=trellis.Constant(100))
Celsius...... 100
Fahrenheit... 212.0

>>> tc.C = -40
Traceback (most recent call last):
  ...
AttributeError: Constants can't be changed

(This would probably be more useful with something like the NoiseFilter example, in that you could set its threshhold to a Constant(), eliminating the need for the filtered rule to check for changes to the threshhold in order to know if it should be recalculated.)

Working With A Component's Cells

As we saw in the main tutorial, the trellis.Cells() API returns a dictionary of active cells for a component:

>>> trellis.Cells(view)
{'model': Value([1, 2, 3, 4]),
 'view_it': Performer(<bound method Viewer.view_it of
                         <Viewer object at 0x...>>, None)}

In the case of a Component, this data is also stored in the component's __cells__ attribute:

>>> trellis.Cells(view) is view.__cells__
True

This makes it possible for you to set up direct links between components using shared cells. It also lets you access cell objects directly, in order to e.g. register their set_value() methods as callbacks for other systems.

Discrete and Performer Cells

To make a cell "discrete" (i.e. automatically resetting to its initial value), you set its third constructor argument (i.e., discrete) to true:

>>> aReceiver = trellis.Cell(value=0, discrete=True)
>>> aReceiver.value
0

>>> v = Viewer(model = aReceiver)
0
>>> aReceiver.value = 42
42
0

As you can see, the value a discrete cell is created with, is the default value it resets to between set (or calculated) values. If you want to make a resetting rule, just include a rule in addition to the default value and the discrete flag.

@perform rules are implemented with the trellis.Performer class:

>>> trellis.Cells(view)['view_it']
Performer(<bound method Viewer.view_it of
           <Viewer object at 0x...>>, None)

The Performer constructor takes only one parameter: a zero-argument callable, such as a bound method or a function with no parameters. You can't set a value for a Performer (because it's not writable), nor can you make it discrete (since that would imply a readable value, and performer cells exist only for their side-effects). Creating a Performer cell schedules it for execution as soon as the current modifier is complete and any normal rules are finished. It will then be re-executed in the future, after any cells or other trellis- managed data structures it depended on are changed. (As long as the Performer isn't garbage collected, of course.)