Archive

Author Archive

Desktop Apps in JavaScript+HTML

March 7, 2014 Leave a comment

Part of the reason I did Eventless (apart from it being fun and explanatory) was so I’d have something almost as convenient as Knockout available to me the next time I had to write a desktop app with a UI. It has now been many years since we could regard web UI development as a hairshirt chore, where we have to make do without the comforts of familiar mature environments and tools. Quite the opposite: whenever I have to write and support a desktop app I curse the fact that I can’t hit F12 and “inspect the DOM” of my UI while it’s running, or immediately debug the code on the tester’s machine when they find a problem.

In the decade-before-last, Microsoft quietly released an IE feature called HTA, or “HTML application”. It’s the neat (but trivially obvious) idea of switching off the usual browser security checks and allowing you to create any ActiveX scriptable objects, so you could write applications with HTML UIs. Neat, but horrible in practise because… well, you had to be there to appreciate the overall shoddiness. And so that’s why they of course had to rush down to the patent office.

But fast forward to the last few years. We can develop complex server or command-line applications in JavaScript using the Node platform and its ecosystem of libraries. We can use a variety of front end languages to fill in the deficiencies of raw JavaScript. The debugging experience inside modern browsers is the best debugging experience anywhere. And so on. It’s well beyond the time for HTAs done right.

It being such an obvious idea, there are a few implementations floating around, but the best I’ve seen is node-webkit. Which is a fine technical name (because it tells you honestly that it’s just node mashed together with webkit), but I think they should pick some cool and memorable “marketing” name for it, because it’s just too brilliant a combination to go without a name of its own. I suggest calling it 长裤. Or failing that, 内裤.

The easiest way to get started with it is to install node, then the nodewebkit package with the -g flag (it’s not a module that extends node; rather, it’s a separate runtime that has its own copy of node embedded). Then you create a package.json with an HTML file as its main:

"main": "index.html"

From that HTML file you can pull in scripts using the script tag in the usual way. But inside those scripts you can use node’s require. Yup.

The sweet combination for me is the beautiful TypeScript, plus the phenomenal Knockout, plus whatever node modules I want to call (along with TypeScript declarations from DefinitelyTyped). This gives me the best of everything: static typing, Chrome-like debugging, the smoothest most scalable/flexible form of two-way binding, the whole works. So I’ll probably never use Eventless in a real project.

I actually started writing a UI for conveniently driving Selenium (which I hopefully will have time to describe soon) in C#/Windows Forms. After getting it all working, I trashed it and switched to node-webkit and it was ridiculous how quickly I was able to get back to the same spot, plus a huge momentum boost from the fun I was having.

(Though admittedly quite a lot of that fun was probably the first flush of joy from using TypeScript.)

(I’m a nerd, did I mention that?)

Categories: Uncategorized Tags: ,

JavaScript for Java programmers

December 7, 2013 2 comments

I just found on my hard drive a talk I gave over two years ago. If you’re a reasonably experienced Java programmer looking for a way to really understand how JavaScript works (especially functions as object, closures, etc.) it may be of help to you:

http://www.youtube.com/watch?v=FGNKoHv7xPY

Categories: Uncategorized Tags: , ,

Rich Text Editor in the HTML Canvas – Part 1: Introducing CAROTA

November 4, 2013 Leave a comment

I’m developing a rich text editor from scratch in JavaScript, atop the HTML5 canvas. It’s called Carota (Latin for carrot, which sounds like “caret”, and I like carrots).

Here is the demo page, which is very self-explanatory, in that it presents a bunch of information about the editor, inside the editor itself, so you can fiddle with it and instantly see how it persists the text in JSON. As you can see, it’s quite far along. In fact I suspect it is already good enough for every way I currently make use of rich text in browser applications. If your browser is old, it will not work. (Hint: IE8 is way old.)

So… Why? What a crazy waste of time when browsers already have the marvellous contentEditable feature, right?

A quick survey of the state-of-the-art suggests otherwise. Google Docs uses its own text layout and rendering system, only using the DOM as low-level display mechanism (the details on that link are very relevant and interesting). Go to Apple’s iCloud which now has a beta of their Pages word processor, and use your browser to look at how they do it: the text is rendered using absolute, meticulously positioned SVG elements, so they too perform their own layout.

And having tried for the last year to get contentEditable to serve my purposes, in the same way on all browsers (actually, even one browser would be something), I can understand why the Twin Behemoths of the Cloud have taken control of their own text layout. So I’m going to do the same thing, but with Canvas. (My previous plan was to do a plugin for Windows so I’d be able to use the Win32 Rich Edit control, but that kind of plugin is about to die out.)

Before I got as far as drawing any text on screen, I had to be very careful to build up a fundamental model of how flowing text actually works. I wanted to end up with beautiful components that each do something extremely simple, and plug together into a working editor. That way it’s easier to change stuff to meet future needs. I’ve designed it from the ground up to be hacked by other people to do whatever they want.

So, hopefully I’ll be back soon to start describing how it works. In the meantime, fork me on github and you can also get the development set-up via the usual:

npm install carota

For a really quick minimal demo, try this jsfiddle, which just creates an editor in an empty DIV and then uses load and save for persistence.

per: composable forward-passing processor functions

October 31, 2013 Leave a comment

The other day I tried implementing SICP streams in JavaScript as part of a fun project I’m tinkering with. I noticed that (unsurprisingly, given how they work) they generate a lot of memory garbage during the main loop of whatever operation you’re doing, and the overhead of this can actually become significant.

So I blogged them, sighed to myself, and then ripped them out of my project. What should I use instead? I want a combination of high performance and convenience. Also I miss generators, which of course I can’t (yet) assume are available on my target platforms, as they include browsers dating as far back as the ancient IE9 (ask your grandmother) and Chrome 30 without the about:flags experimental JavaScript features enabled.

My building block will be a function of this shape, which I’ll refer to as a processor:

function timesTwo(emit, value) {
    emit(value * 2); // this part is optional
}

It takes two parameters, the first being a function to which it can pass values forward, and then second being a value for it to process. So you have to call it to give it a value, and it may or may not emit values onwards to wherever you tell it.

Of course it can emit nothing, or many values:

function triplicate(emit, value) {
    emit(value);
    emit(value);
    emit(value);
}

If you’re into Ruby this will be very familiar to you as a way of representing a sequence of values, and if you implement this kind of function it’s nice and easy, like using yield in a true generator.

The difference here from the Ruby pattern is that we’re discussing a pure function, rather than a method on an object. So we take a second argument as an input that can be used to determine what we emit. For example, we could assume our values will be arrays, and “flatten” them:

function flatten(emit, value) {
    value.forEach(emit); // JS array's forEach fits perfectly
}

If you called this three times passing an array each time, emit would get all the elements of the three arrays as a flat stream of elements (in separate calls), not knowing which arrays they were originally from.

Alternatively we can ignore the second parameter (not even bothering to declare it) and so define a pure source of data that emits its sequence of values when called:

function chatter(emit) {
    emit('hi');
    emit('whatever');
    emit('bye');
}

So far, so patterny. But the pain with these kinds of building blocks is that they don’t directly compose. An intermediate processor like flatten wants two arguments: where to emit its output and what value to process. But any preceding step just wants a function called emit that accepts one argument: a value.

We can take any two processors and turn them into a single processor that chains the two (put on your higher-order functional programming spectacles now):

function compose(first, second) {
    return function(emit, value) {
        return first(function(firstValue) {
            return second(emit, firstValue);
        }, value);
    };
}

(Note: I pass back the return value through the layers because it has a use that we’ll go into later.)

See how it works? compose creates and returns a new function. It weaves first and second together. The new wrapper receives the outer emit, and that is given to second, so that’s where the final results will be sent. The first function is passed another new function to emit to, which is where we call second.

That’s the beautiful version. But it means that we have allocate a function object every time a value is passed in. And let’s be crazy C++ programmers for a moment and assume that’s Just Not Good Enough. We could rewrite compose to be butt-ugly and yet still do what we want, without doing any dynamic allocation after initial setup:

function compose(first, second) {
    var secondEmit;
    function firstEmit(firstVal) {
        return second(secondEmit, firstVal);
    }
    return function(emit, value) {
        secondEmit = emit;
        return first(firstEmit, value);            
    };
}

Yes, EEWWW indeed. We use a local variable, secondEmit, in which we stash the outer emit as soon as we know it. And we create a firstEmit function once, so we can reuse it.

In simple scenarios this will behave the same as the beautiful version. But not always:

function troubleMaker(emit, value) {
    setInterval(function() { emit(value); }, 100);
};

var doubleTrouble = compose(troubleMaker, timesTwo);

doubleTrouble(function(value) { console.log(value); }, 3);
doubleTrouble(function(value) { document.write(value); }, 4);

Now we have the value 6 being printed to the console and the value 8 being appended to the document. Except… not if we use the second version of compose, because then the second call to foo would redirect both streams to the new destination (by updating that secondEmit local variable). What a mess.

Fortunately, we’re not C++ programmers! Phew! This doesn’t mean that we don’t care about performance. It just means that we do some measuring before going crazy about imaginary overhead. And on V8 I find that the “faster” version is approximately… 1% faster. Screw that. Let’s stick with the beautiful, easy-to-predict version.

The one other interesting feature of the pattern is what we can use the return value for: to signal that the receiver doesn’t want to receive any more data. To do this they return true. So our flatten example should actually look like this:

function flatten(emit, value) {
    return value.some(emit);
}

That way, we stop looping unnecessarily when there’s no need to keep going (because that’s what a JavaScript array’s some method does: quits and returns true when the function you gave it returns true).

So that’s the pattern. What more is there to say? Well, although writing a processor (or pure value generator) is very easy, because you just write imperative code and call emit whenever you like, it’s not so convenient to use them as components. Yes, we have combine to efficiently pipeline processors together, but there are a lot of “standard” things we tend to do on sequences where it would be nice not to have to write boilerplate code. Especially when writing tests (shudder).

To make this really easy and succinct, I’ve cooked up a little library called per:

npm install per

(Source code)

It’s reminiscent of jQuery, in that it puts a lightweight wrapper around something so that we can call useful operations on it. Most operations return another instance of the wrapper, so calls can be chained. The only entry point into the whole library is a single function called per, so in node (or browserify or webmake) you’d say:

var per = require('per');

In the browser you could just load per.js via the script tag and then you get a global per. Then you can wrap functions like this:

var numbers = per(function(emit) {
    for (var n = 0; n < 100; n++) {
        emit(n);
    }
});

The simplest methods on a per are ways to capture and return the emitted values:

var f = numbers.first(),    // f == 0
    l = numbers.last(),     // l == 99
    a = numbers.all()       // array [0... 99]

The function wrapped by a per is available in a property called forEach, so named because for a simple generator you can treat it a little like an array:

numbers.forEach(function(value) {
    console.log(value);
});

To compose functions, there is a per method which is exactly like the compose function we figured out above.

var odds = numbers.per(function(emit, value) {
                           if (value % 2) {
                               emit(value);
                           }
                       });

The above pattern is an example of a filter, which evaluates an expression to decide whether or not to forward a value. This is such an obvious pattern that we should have a built-in formalization of it:

var odds = numbers.filter(function(value) {
                              return value % 2
                          });

For extra brevity we support passing a string expression in terms of x:

var odds = numbers.filter('x%2');

Another common pattern is to transform a value and pass it on, which is captured by the map method:

var evens = numbers.filter('x%2').map('x-1');

How can we use the resulting combination? As always it has a forEach property, and because numbers doesn’t need a value parameter we only need to pass it a function to emit to (or we can use first, last or all).

There are operators skip and take that work like their corresponding Linq operators:

odds.skip(3).all()          // [7, 9, 11, 13...]
odds.skip(2).take(3).all()  // [5, 7, 9]

These are examples of stateful transformers, because they have an internal counter that controls their behaviour.

We can also construct an initial per by passing an array:

var a = per([1, 2, 3, 4, 5]);

console.log(a.first()); // 1
console.log(a.last()); // 5

You can even pass per a simple value and it will act as a function that merely emits that one value. For example that value might be something complex, such as a whole document that you’re going to pass through several parsing stages.

The above examples all use a fairly simple structure: the first call to per provides an initial value (or stream of values), then there is a chain of transformations, then the final step collects the results. This is fine if you want to process a stream of data in a single quick operation.

But what if you have a source of data that occasionally delivers you a value, and you want to send it through a pipeline of transformers? That is, rather than a single deluge you have more of a drip, drip, drip of information. You can prepare a chain of transformers:

var p = per(foo1).per(foo2)
                 .map(bar1)
                 .filter(bar2)
                 .listen(function(value) {
                     console.log(value);
                 });

The listen is used to inject a function in the pipeline that just receives values, but otherwise has no effect on the stream. So in fact it’s like per but you don’t have to write emit(value) – that just happens automatically.

So now you need a way to pass values into the front, for which you can use submit:

p.submit(5);
p.submit(41);
p.submit('hi');

Sometimes you need to direct the flow of information through multiple separate sections simultaneously. This is where multicast comes in handy:

var p = per(foo1).per(foo2).multicast(
    per(foo1).filter('!(x%2)').take(72).into(results1),
    per(foo2).filter('x%2').take(68).into(results2)
);

You can pass as many arguments as you like to multicast (they can be instances of per or plain transformer functions) and they will each receive every value. By the way, multicast is built on listen, so it doesn’t affect the stream, except that when all the recipients have returned true to indicate that they are full, then multicast itself will do the same.

But really the core idea is break up a complex multi-stage task into functions like this:

function transformer(emit, value) {
    // do something interesting and maybe call emit
    // a few times, passing forward values to the next stage
}

The per library merely provides some common ways to stitch such functions together.

Categories: Uncategorized Tags: ,

SICP-style Streams in JavaScript

October 29, 2013 1 comment

In the not-famous-enough book Structure and Interpretation of Computer Programs (Abelson & Sussman, or “The Wizard book”) we learn about streams.

A stream is a tempting variation on the old school Lisp style of linked list. To get a plain old list, we can set up objects like this:

var a = {
    value: 'apple',
    next: null
};

var b = {
    value: 'banana',
    next: a
};

var c = {
    value: 'cantaloupe',
    next: b
};

So here our whole list is represented by c, and we can loop through it and print all the fruits:

for (var i = c; i != null; i = i.next) {
    console.log(i.value);
}

So far, so boring. The idea with a stream is very simple. Instead of storing the next object in the next property, we store a function that, if called, will return the next object. That is, we make it lazy. Note that our loop would still look much the same:

for (var i = c; i != null; i = i.next()) {
    console.log(i.value);
}

The only difference is we call next() instead of just reading it. And to set up the objects we’d have to say:

var a = {
    value: 'apple',
    next: function() { return null; }
};

var b = {
    value: 'banana',
    next: function() { return a; }
};

var c = {
    value: 'cantaloupe',
    next: function() { return b; }
};

So far, so pointless. But the value of this does not come from silly hand-built examples. In real software you would use this to generate streams from other data sources, or from other streams. It’s like Linq-to-objects in C#, but the foundations are actually more purely functional, because even the iteration process involves only immutable objects, and so everything is repeatable, nothing is destroyed merely by using it. Part-way through a stream you can stash the current node, and come back to it later. It will still represent “the rest of the stream”, even though you already used it once.

It is this extreme level of generality that persuaded me try using streams in a real JavaScript library. I want to write a rich text editor for HTML Canvas (more of that in a later post, hopefully). So I would have streams of characters, streams of words, streams of lines, etc. It seemed to fit, and also I have a week off work and it’s fun to re-invent the wheel.

I start with an object representing the empty stream. This is nicer than using null, because I want to provide member functions on streams. If you had to check whether a stream was null before calling methods on it, that would suck mightily.

var empty = {};

function getEmpty() {
    return empty;
}

Then we need a way to make a non-empty stream:

function create(value, next) {
    return Object.create(empty, {
        value: { value: value },
        next: { value: next || getEmpty }
    });
}

It uses the empty stream as its prototype, and adds immutable properties for value and the next function. If no next function is passed, we substitute getEmpty. So calling create('banana') would make a stream of just one item.

One very handy building block is range:

var range = function(start, limit) {
    return start >= limit ? empty : create(start, function() {
        return range(start + 1, limit);
    });
};

Note the pattern, as it is typical: the next works by calling the outer function with the arguments needed to make it do the next step. And you may be thinking – AHGGHGH! Stack overflow! But no, as long as we loop through the stream using our for-loop pattern, the stack will not get arbitrarily deep.

Here’s a favourite of mine, so often forgotten about:

var unfold = function(seed, increment, terminator) {
    return create(seed, function() {
        var next = increment(seed);
        return next === terminator ? empty :
            unfold(next, increment, terminator);
    });
};

You call it with a seed value, which becomes the first value of the stream, and also an increment function that knows how to get from one value to the next, and a terminator value that would be returned by the increment function when it has no more values. So in fact you could implement range in terms of unfold:

var range = function(start, limit) {
    return unfold(start, function(v) { return v + 1; }, limit);
};

It can also turn a traditional linked list into a stream:

var fromList = function(front) {
    return unfold(front, function(i) { return i.next; }, null);
};

Groovy! Now we have several ways to originate a stream, so lets add some methods. Recall that empty is the prototype for streams, so:

empty.forEach = function(each) {
    for (var s = this; s !== empty; s = s.next()) {
        each(s.value)
    }
};

Nothing to it! And we can use forEach to get a stream into an array:

empty.toArray = function() {
    var ar = [];
    this.forEach(function(i) { ar.push(i); });
    return ar;
};

Of course, how could we live without the awesome power of map?

empty.map = function(mapFunc) {
    var self = this;
    return self === empty ? empty : create(mapFunc(self.value), function() {
        return self.next().map(mapFunc);
    });
};

Again, that lazy-recursive pattern. And now we can very easily implement converting an array into a stream:

var fromArray = function(ar) {
    return range(0, ar.length).map(function(i) {
        return ar[i];
    });
}

How about concat? Well, this has a slight wrinkle in that if the argument is a function, I treat it as a lazy way to get the second sequence:

empty.concat = function(other) {
    function next(item) {
        return item === empty
            ? (typeof other === 'function' ? other() : other)
            : create(item.value, function() { return next(item.next()); });
    }
    return next(this);
};

And with concat we can easily implement the holy grail of methods, bind (known as SelectMany in Linq and flatMap in Scala):

empty.bind = function(bindFunc) {
    var self = this;
    return self === empty ? empty : bindFunc(self.value).concat(function() {
        return self.next().bind(bindFunc);
    });
};

Think that one through – it’s a mind-bender. The bindFunc returns a sub-stream for each item in the outer stream, and we join them all together. So:

assertEqual(

    // ordinary array of numbers
    [1, 2, 3, 4, 5, 6, 7, 8, 9],

    // making that same array in an interesting way
    Stream.fromArray(
        [[1, 2, 3], [4], [5, 6], [], [7], [], [], [8, 9]]
    ).bind(function(ar) {
        return Stream.fromArray(ar);
    }).toArray()

);

Anyway, I wrote my rich text layout engine using this stream foundation, and (as I like to do with these things) I set up an animation loop and watched it repeatedly carry out the entire word-break and line-wrap process from scratch in every frame, to see what frame rate I could get. Sadly, according to the browsers’ profilers, the runtime was spending a LOT of time creating and throwing away temporary objects, collecting garbage and all the other housekeeping tasks that I’d set for it just so I could use this cool stream concept. Interestingly, in terms of this raw crunching through objects, IE 10 was faster than Chrome 30. But I know that by using a simpler basic abstraction it would be much faster in both browsers.

How do I know? Well, because I found that I could speed up my program very easily by caching the stream of words in an ordinary array. And guess what… I could just use arrays in the first place. I am only scanning forward through streams and I definitely want to cache all my intermediate results. So I may as well just build arrays. (Even though I haven’t started the rewrite yet, I know it will be way faster because of what the profilers told me).

So, for now, we say: fair well streams, we hardly knew ye.

Eventless Programming – Part 5: Async/Await and Throttling

March 3, 2013 2 comments

Posts in this series:

Last time we were able to throw a few more working features into our UI with relatively little effort, following very simple patterns. The result is that the UI automatically updates itself according to every change the user makes to the state of a control.

Which raises the question: what if that involves working a little too hard? If the user makes half a dozen changes in quick succession (say, they impatiently click the “Increase Radiation” button five times) then it makes little sense to do a ton of work to update the UI after every single click. It would be wiser to wait until they stop clicking it for half a second or something.

This is especially important when the updating work involves something really costly like downloading content over the network. And that’s another point – how do we integrate with asynchronous background calls? Oh no, my whole universe is starting to crumble!

Except it’s not. There are simple answers to both questions. Let’s start with the rapid-fire-recomputations problem. Recall that in our Notes view model, we cook up this:

SelectedNotes = Computed.From(
    () => AllNotes.Where(n => n.IsSelected.Value).ToList());

This means that every time you check or uncheck the selection CheckBox for a note, a Where/ToList is re-executed, and then various bits of UI infrastructure get rejigged as a result of SelectedNotes changing. In fact we can easily monitor how often this happens by adding this line:

Computed.Do(() => Debug.WriteLine("SelectedNotes: " + SelectedNotes.Value.Count()));

Now try clicking Select all and you’ll see the crazy results:

SelectedNotes: 0
SelectedNotes: 1
SelectedNotes: 2
SelectedNotes: 3
SelectedNotes: 4
SelectedNotes: 5
SelectedNotes: 6
SelectedNotes: 7
SelectedNotes: 8
SelectedNotes: 9
SelectedNotes: 10
SelectedNotes: 11
SelectedNotes: 12
SelectedNotes: 13
SelectedNotes: 14
SelectedNotes: 15
SelectedNotes: 16

Yes, as we loop through the notes setting IsSelected to true, every single time the SelectedNotes list is recomputed and so triggers UI updates. It may not be a problem in this little example, but it’s not to hard to see how it could become a problem if the UI update were more expensive.

So that’s why it needs to be this easy to fix it:

SelectedNotes = Computed.From(
    () => AllNotes.Where(n => n.IsSelected.Value).ToList()
).Throttle(100);

Yep, you just tack .Throttle(100) on the end, and it configures the Computed to wait until it hasn’t been notified of a change in its dependencies for at 100 milliseconds before acting on it; that is, it waits for stability. There’s actually a second parameter bool that lets you select between two behaviours:

1. true: wait for n milliseconds of stability (the default)
2. false: recompute no more than once every n milliseconds during instability

The default behaviour means that if the user keeps making changes back and forth indefinitely, the UI will never update. But of course in reality they don’t do that, so it’s usually fine. But if you wanted to show continuous feedback while (say) the user drags a slider, maybe the second behaviour would be more suitable. There’s no hard and fast rule here, which is why it’s an option.

Now let’s do some asynchronous downloading. Say we have a TextBox where the user types a URL, and we are going to download it automatically as they type. In reality they’d be adjusting a more restricted set of parameters than just a raw URL, of course, but it serves as an example. First we’d bind the TextBox to a Setable.

var urlText = Setable.From(string.Empty);
textBoxUrl.BindText(urlText);

Then from that we’d compute a Uri object, or null if the string isn’t yet a valid URI.

var uri = Computed.From(() =>
{
    Uri result;
    Uri.TryCreate(urlText.Value, UriKind.Absolute, out result);
    return result;
});

So far, so obvious. But it turns out the last part isn’t too surprising either:

var response = Computed.From(async () =>
{
    if (uri.Value == null)
        return "You haven't entered a valid url yet...";

    try
    {
        return await new HttpClient().GetStringAsync(uri.Value);
    }
    catch (HttpRequestException x)
    {
        return "Error: " + x.Message;
    }
}).Throttle(1000);

You just put the async keyword in front of the lambda you pass into Computed.From (and of course you should probably use Throttle, as I’ve done here). So what is response? It’s an IGetable, as you’d expect, but what type of Value does it hold? By inspecting the various return statements of our lambda, it’s pretty clear that it returns a string, but it is an async lambda so therefore it returns Task<string>.

But Computed.From has a special overload for Task<T> that takes care of await-ing the result value. So the upshot is that response is simply a IGetable<string> and can immediately be bound to a control:

textBoxResponse.BindText(response);

When used inside a UI application, async/await automatically ensures that if you launch a task from the UI thread and await it, the await will return on that same UI thread. So your UI code never has to worry about threads much at all, which is very reassuring (it’s not like the old days, when you had to manually use Control.Invoke to ensure that your UI updating operations happened on the right thread).

The complete source code for this series of articles is available here:

https://github.com/danielearwicker/eventless

It’s a Visual Studio 2012 solution.

Next time… well, actually I’m going to pause here for a while. The next step would be to see how we can apply these ideas to a more current UI framework like Windows Runtime. In the meantime, I hope it’s been interesting to see how the core ideas of Knockout are applicable in environments that have nothing to do with HTML and JavaScript, and it’s not actually about binding to the UI. The key thing is providing a highly productive way to transform your raw data. That’s what makes the binding part easy. So unless you make the data transformation easy, then you’ve just moved the problem without solving it. Computed observables are what make it possible to declare your data transformations, and so enable eventless programming. They are the secret sauce of Knockout.

Categories: Uncategorized Tags: , ,

Eventless Programming – Part 4: More Views Than You Can Shake A Stick At

March 2, 2013 Leave a comment

Posts in this series:

Last time we got a basic UI together. Next we’ll throw lots of typical ingredients into it, but common theme will be: everything stays consistent. And there ain’t much code.

First of all, just to follow a tidy pattern, we’ll define a proper “view model” class for our main Form:

public class Notes
{
    public readonly ISetableList<Note> AllNotes = new SetableList<Note>();
    public readonly IGetable<IEnumerable<Note>> SelectedNotes;
    public readonly ISetable<Note> ActiveNote = new Setable<Note>();

    public Notes(IEnumerable<string> initialNotes)
    {
        AllNotes.AddRange(initialNotes.Select(
            text => new Note(this) { Text = { Value = text } }));

        SelectedNotes = Computed.From(
            () => AllNotes.Where(n => n.IsSelected.Value).ToList());
    }

    public void Add(string note)
    {
        AllNotes.Add(new Note(this) { Text = { Value = note } });
    }
}

This is just the same code as before, minus any bindings to UI controls. The idea is that you could then make a bunch of different views that bind to the same data (and of course, you can write unit tests). We won’t bother to do that with the whole Notes system, but we will do it for individual notes. I just wanted to neaten this up before continuing.

There is one new thing: the ActiveNote property. Nothing fancy, it just holds a single Note (or null, of course).

I’ve changed Note so it takes a reference to Notes in its constructor (oh yes, it has a constructor now):

public class Note
{
    public readonly ISetable<string> Text = new Setable<string>();
    public readonly ISetable<bool> IsSelected = new Setable<bool>();
    public readonly ISetable<NotePriority> Priority = new Setable<NotePriority>();
    public readonly ISetable<bool> IsActive;
        
    public Note(Notes notes)
    {
        IsActive = Computed.From(
            get: () => notes.ActiveNote.Value == this,
            set: value =>
                {
                    if (value)
                        notes.ActiveNote.Value = this;
                    else if (notes.ActiveNote.Value == this)
                        notes.ActiveNote.Value = null;
                }
        );
    }
}

This allows it to set up its own new IsActive property that is true only if this property is currently the active one. It’s Computed with a getter and a setter, so it provides a different way to interact with Notes.ActiveNote:

noteA.IsActive = true; // activeNote is now noteA
noteB.IsActive = true; // activeNote is now noteB
noteB.IsActive = false; // activeNote is now null

So although it looks like each Note has an independent bool property, they are utterly co-dependent. Only one can be true at a time. Compare this to the typical hacky approach where you actually give each Note a separate bool and then try to keep them in line by manually setting them. How much more elegant to just declare how to simulate a bool property by using a single shared ActiveNote property. It’s pure poetry!

The main NotesForm just sets up the binding to UI controls. In fact I’ve made it implement IBindsTo<Notes> just to follow the pattern. But really this is the same code as before, just rearranged. Oh, I added the concept of NotePriority:

public enum NotePriority
{
    Normal, Low, High
}

So Note has an setable Priority as well. So we have a couple of new things we could bind to in NoteListItemForm:

public void Bind(Note note)
{
    textBoxContent.BindText(note.Text);
    checkBoxIsSelected.BindChecked(note.IsSelected);

    Computed.Do(() => BackColor = note.IsActive.Value
                            ? SystemColors.Highlight
                            : SystemColors.Window);

    Computed.Do(() => pictureBox.Image = 
        note.Priority.Value == NotePriority.High ? Properties.Resources.high :
        note.Priority.Value == NotePriority.Low ? Properties.Resources.low :
        null);

    textBoxContent.Click += (s, ev) => note.IsActive.Value = true;
}

This is a chance to show how you can bind anything in your UI, even if there isn’t a special extension method for whatever it may be. The trick is to use Computed.Do, which we haven’t used so far. It’s just like Computed.From but it returns void and takes a plain Action. Now what the heck is the point of that? A computed observable that computes nothing and gives you back nothing to observe? Oh but it does! As with any void function, it returns a new version of the universe. Or more mundanely, it has side effects on this universe. Or even more mundanely, it has side-effects on some control in our UI.

The beauty of it is that it runs the action once when you set it up, and then again whenever anything it depends on changes. So although you have to write imperative side-effecting statements, they are typically just assignments, and the right-hand side is an expression in terms of observables, just like you’d use in a binding. So it’s a way to roll your own kind of binding. Here I have two examples: the background color is different for the active note, and an icon is used for the two non-normal priorities:

part4-active-icons

There’s also a plain old Click event handler so the user has a way to set this Note to be the active one.

We can also display a more expanded view of the active note, using another small form called NoteEditingForm, which implements IBindsTo<Note> in the usual way.

part4-active

Edit the text in the active view and it immediately changes in the list, and vice versa. Cool!

This is ridiculously easy. On the main form we add a new empty Panel, and then we bind it like this:

panelActiveNote.BindContent(notes.ActiveNote).As<NoteEditingForm>();

That’s it. BindContent is actually a close relative of BindForEach, the difference being that it uses a single value that may be null, which we could think of as a list that has either zero items or one item. NoteEditingForm has one minor thing we haven’t seen previously: binding to radio buttons:

public void Bind(Note note)
{
    textBoxContent.BindText(note.Text);
    checkBoxIsSelected.BindChecked(note.IsSelected);

    radioButtonHigh.BindChecked(note.Priority, NotePriority.High);
    radioButtonNormal.BindChecked(note.Priority, NotePriority.Normal);
    radioButtonLow.BindChecked(note.Priority, NotePriority.Low);
}

Easy-peasy. Okay, so what else could we do? What if there was an alternative view where we just show you a big scrollable list of these NoteEditingForm tiles? Sounds like a lot more work… No, you dummy! It’s just this:

panelEditors.BindForEach(notes.AllNotes).As<NoteEditingForm>();

And immediately we have this:

part4-editors

Of course, you can edit in one view and it changes in all the others. They’re all bound to the same simple underlying view model, and the bindings are declarative, and therefore hard to get wrong. It makes the UI very malleable – you can very quickly try out ideas, move pieces around, and know that the pieces will keep working. And that in turn gives you the power to make a better UI, because experimentation (with feedback from real users, even if that’s just yourself) is the only way to make a better UI.

Code in the usual place. Next time, how we can integrate with async/await, and use throttling to reduce the rate of recomputation.

Categories: Uncategorized Tags: , ,

Eventless Programming – Part 3: Binding to a UI

March 2, 2013 Leave a comment

Posts in this series (and if you’ve been following so far, have another quick read-through – there’s been some renaming again…):

Last time we figured out how to create a second kind of observable, one that defines its value using a function. The burning question is: how are we going to tie these things to a UI?

Consider knockout, the inspiration for this whole exercise. There, the UI is defined by HTML. Special data-bind attributes are added to easily link observables up to various properties.

Now, in the C# Windows GUI world there has been some turmoil over the last year or so (to put it mildly). Do we go with WPF, Silverlight or Windows Runtime? Wait a second, we’re forgetting poor old reliable, sleepy, uncontroversial, it-just-works Windows Forms! For fun, let’s start by rewriting the past. How should we have been making Windows apps in 2003?

Aside from anything else, Windows Forms has a very easy to use GUI design tool for us to layout controls on. But there’s no “mark-up” for us to extend with custom attributes. Aw, don’t cry! We’re not going to give up just yet. We can just provide a way to set up bindings from code and it’s all going to be fine.

var newNoteText = Setable.From(string.Empty);

textBoxNewNote.BindText(newNoteText);

// 'Add' button is only enabled if text box is non-empty
buttonAdd.BindEnabled(Computed.From(() => newNoteText.Value.Length != 0));

See how it works? I declare a Setable, and then I have an extension method on TextBox called BindText that I can call to bind the TextBox to the Setable.

Then I have a Button I want to enable only when the TextBox is non-empty. Instead of having to say what steps to carry out and when to carry them out (“evented” imperative programming), I just declare the facts that must be true at all times, under all states the system might get into, also known as the invariants of the system.

So our pattern here is simply to define extension methods on the existing standard Windows Forms controls, with names like BindSomething, where Something is one of those properties that has an associated event SomethingChanged.

The implementation would not be particularly tricky, were it not for one thing: we will need a convenient way to unbind all the event bindings we set up. This is not always necessary, but when you have a very dynamic UI with chunks of content appearing and disappearing, or one chunk being re-used to bind to different objects, it’s essential.

We can use an approach inspired by transactions, where we capture a log of actions that will (when “played back”) unbind everything that has been bound. To see how it works, let’s start with something very simple. Here’s the implementation of a fundamental binding for practically all interesting controls: Enabled.

public static void BindEnabled(this Control control, IGetable<bool> to)
{
    BindChanged(to, () => control.Enabled = to.Value);
}

It’s a one-way binding, obviously, because the user can’t change the “enabledness” of a control. Hence we only need IGetable, and we only need to say what we’re going to do when the observable changes: no need to bind to an event on the control. Here’s BindChanged:

public static void BindChanged<T>(IGetable<T> getable, Action changed)
{
    changed();
    getable.Changed += changed;
    BindingLog.Notify(() => getable.Changed -= changed);
}

The first thing it does is run the changed action we pass in, so that the control will be initialised to match the state of getable. Then it subscribes to the Changed event and finally it “logs” an action that would, if called, unsubscribe from that event. And so how is BindingLog implemented? Why, it’s our old friend from part 2:

private static readonly ListenerStack<Action> BindingLog = new ListenerStack<Action>();

And so elsewhere, whenever we want to do some random binding and capture an action that we execute later to undo that binding, we should carry out the binding activity inside a context:

public static Action CaptureUnbind(Action bindingActivity)
{
    try
    {
        Action multicastUnbinders = null;
        Log.Push(nestedUnbinder => multicastUnbinders += nestedUnbinder);
        bindingActivity();
        return multicastUnbinders ?? EmptyAction;
    }
    finally
    {
        Log.Pop();
    }
}

[Trivia: Whenever you are building up a list of actions so that later you can loop through them all and execute them, remember that C# actually has language support for that pattern: the multicast delegate. You can say action += anotherAction and now action has been replaced by a new action that calls the original two actions.]

Usage:

var unbind = Binding.CaptureUnbind(() =>
{
    textBoxNewNote.BindText(newNoteText);

    buttonAdd.BindEnabled(Computed.From(
          () => newNoteText.Value.Length != 0));

    // Any other bindings in this batch...
});

And then to unbind:

unbind();

So, to business. Here’s version one of my simple demo UI.

notetaker2

You can type in the top text box to enter a new “note”, by clicking Add. We display the current list of notes in a checked list box. You can check items and then click Delete to delete all checked items. And you toggle selection of all/none by clicking the Select all check box. It’s a nice example because the things on the screen are related in ways that aren’t as simple as they first appear.

In persistent terms, a note is just a string. But in our UI, a note is also either selected or not. So we really should model a note like this;

public class Note
{
    public readonly ISetable<string> Text = new Setable<string>();
    public readonly ISetable<bool> IsSelected = new Setable<bool>();
}

Now, you might be tempted to “correct” this as follows, in order to do things by-the-book (what are you, the encapsulation police?):

public class Note
{
    private readonly ISetable<string> _text = new Setable<string>();
    private readonly ISetable<bool> _isSelected = new Setable<bool>();

    public ISetable<string> Text { get { return _text; } }
    public ISetable<bool> IsSelected { get { return _isSelected; } }
}

But in this simple example (and many real-world cases), it would add nothing. Each of our properties is already encapsulated behind ISetable, which gives us total flexibility in the future to change how they are implemented internally without affecting our clients. ISetable is just another way of encapsulating a mutable property, with the added bonuses that (a) we can pass around a reference to it where necessary (rather like a “property delegate”, something absent from C# itself), and most important of all (b) it has a built-in Changed event.

Now we need a little nugget of UI to represent a note in the list. I’ll do something a bit weirder than a mere CheckBox, just to demonstrate a more powerful capability. We’ll define a new Form-derived class, NoteListItemForm, which is laid out very compactly:

noteitem1

There’s a CheckBox without a label, so next to it I can put a TextBox. This will mean that the user can edit the note text directly in the list (though it will make selection a bit less intuitive – however, we’ll come back to that).

The code-behind for this mini-form is very simple:

public partial class NoteListItemForm : Form, IBindsTo<Note>
{
    public NoteListItemForm()
    {
        InitializeComponent();
        TopLevel = false;
        Visible = true;
    }

    public void Bind(Note note)
    {
        textBoxContent.BindText(note.Text);
        checkBoxIsSelected.BindChecked(note.IsSelected);
    }
}

In the constructor we make the standard changes necessary to make it suitable for adding as a child of a Panel. Then there’s just a Bind method that wires it up to a Note (thanks to the magic unbinding context we built above, there’s never a need to write a corresponding Unbind method). By the way, that Bind method implements the IBindsTo interface, which will turn out to be important in a moment.

Strange as it may seem, the rest of our code can be put very neatly in the constructor of our main Form-derived class. First we declare the list of notes:

var notes = new SetableList<Note>();

Then we have a large Panel on our main Form where we’d like the list to appear. There’s a rather nifty extension method on Panel that we can use like this:

panelSelectionList.BindForEach(notes).As<NoteListItemForm>();

It has a slightly peculiar chained declaration, just to get the most out of type inference. BindForEach only needs one direct parameter, an ISetableList<TItem>, which is the source of data. Then that returns something on which you have to call As, which only needs a type parameter. Here that is our mini-Form, but it could be any class derived from the Windows Forms Control class which implements the IBindsTo interface and has a parameter-less constructor – or to put it another way:

where TControl : Control, IBindsTo<TItem>, new()

Every time the contents of the list change, the binding automatically creates (or destroys) child controls in the panel, laying them out vertically, and calling each child control’s Bind method to set it up. (Important: this only happens when we put different Note objects in the list. Nothing has to happen here when one of the internal properties of a Note changes, because those have their own bindings.)

Next we arrange for new notes to be added by the user (which is actually the same code I used as an example above):

var newNoteText = Setable.From(string.Empty);
textBoxNewNote.BindText(newNoteText);

// 'Add' button only enabled if text box is non-empty
buttonAdd.BindEnabled(Computed.From(() => newNoteText.Value.Length != 0));

buttonAdd.Click += (s, ev) =>
{
    notes.Add(new Note { Text = { Value = newNoteText.Value } });
    textBoxNewNote.Text = string.Empty;
    textBoxNewNote.Focus();
};

Oh look! An actual explicitly wired-up event handler. Button.Click is the only kind of event we should ever have to deal with like this: it’s intrinsically imperatively by nature. Otherwise, it’s declaration everywhere, including our first Computed.

A more thorny problem is that of the Select all CheckBox, which has three states. If we only select some of the notes, the CheckBox should be “indeterminate”. But with a couple more Computeds we can declare what we want it do and it’s really very easy, even though it would be surprisingly gnarly in traditional evented-imperative code.

Firstly, lets compute ourselves a list of just those notes that are currently selected (which is going to be useful for the Delete button also):

var selectedNotes = Computed.From(() => notes.Where(n => n.IsSelected.Value).ToList());

Two things to note:

  1. Just because it’s a list, it doesn’t need to be an ISetableList. It’s just an ordinary IGetable that happens to contain a computed list as its value.
  2. It’s really important that we say ToList(), because we have to access the IsSelected property directly during the execution of the lambda we pass to Computed.From, otherwise the library can’t detect our dependency on that property. If we leave it as a lazily evaluated list, we apparently won’t be dependent on anything.

But how do come up with something we can bind to our three-state checkBoxAllNotes? There is a suitable binding extension method, BindCheckState, that supports all three states using the standard enum CheckState as the value. But what about the value we’ll bind to?

Happily there’s another trick up our sleeves: the setable computed. This essentially lets you define on-the-fly a property with custom getter and setter methods.

checkBoxAllNotes.BindCheckState(Computed.From(

    get: () => selectedNotes.Value.Count == 0
                    ? CheckState.Unchecked
                    : selectedNotes.Value.Count == notes.Count
                            ? CheckState.Checked
                            : CheckState.Indeterminate,

    set: state =>
        {
            // only pay attention when setting to a definite state
            if (state == CheckState.Indeterminate)
                return;

            foreach (var note in notes)
                note.IsSelected.Value = state == CheckState.Checked;
        }));

We’re using an overload of Computed.From that takes two parameters, get and set. I’m using named parameter syntax even though its totally redundant here, just for clarity (and because it resembles the declaration of a property).

The getter lambda literally says: “if none are selected I’m unchecked; if all are selected I’m checked; otherwise I’m indeterminate.” The setter is even simpler: it sets all the notes to be either selected or not selected, depending on whether the new state is Checked or Unchecked. If the new state happens to be Indeterminate, it does nothing.

And we don’t really need this dang CheckBox to work at all if there aren’t currently notes to select:

checkBoxAllNotes.BindEnabled(Computed.From(() => notes.Count != 0));

Now the Delete button is child’s play:

buttonDelete.BindEnabled(Computed.From(() => selectedNotes.Value.Count != 0));
buttonDelete.Click += (s, ev) => notes.RemoveAll(selectedNotes.Value);

Recall that all this is in the constructor of our main Form. To recap:

var notes = new SetableList<Note>();
            
// For each each note, make a CheckedListBoxItem
panelSelectionList.BindForEach(notes).As<NoteListItemForm>();

var newNoteText = Setable.From(string.Empty);
textBoxNewNote.BindText(newNoteText);

// Add button only enabled if text box is non-empty
buttonAdd.BindEnabled(Computed.From(() => newNoteText.Value.Length != 0));
buttonAdd.Click += (s, ev) =>
{
    notes.Add(new Note { Text = { Value = newNoteText.Value } });
    textBoxNewNote.Text = string.Empty;
    textBoxNewNote.Focus();
};

// list of currently selected notes (important: ToList to avoid lazy evaluation)
var selectedNotes = Computed.From(() => notes.Where(n => n.IsSelected.Value).ToList());

// Two-way binding
checkBoxAllNotes.BindCheckState(Computed.From(

    get: () => selectedNotes.Value.Count == 0
                    ? CheckState.Unchecked
                    : selectedNotes.Value.Count == notes.Count
                            ? CheckState.Checked
                            : CheckState.Indeterminate,

    set: state =>
        {
            // only pay attention when setting to a definite state
            if (state == CheckState.Indeterminate)
                return;

            foreach (var note in notes)
                note.IsSelected.Value = state == CheckState.Checked;
        }));

checkBoxAllNotes.BindEnabled(Computed.From(() => notes.Count != 0));

// Delete button only enabled if selection is non-empty
buttonDelete.BindEnabled(Computed.From(() => selectedNotes.Value.Count != 0));
buttonDelete.Click += (s, ev) => notes.RemoveAll(selectedNotes.Value);

You can get the code from GitHub to see the NoteTaker application in action. Next time on this channel: let’s make the UI unnecessarily complicated and powerful, so it has multiple simultaneously updating views on the same information, all of which stay mutually consistent, yet we barely have to write any more code.

Categories: Uncategorized Tags: , ,

Eventless Programming – Part 2: Computed observables

February 28, 2013 Leave a comment

Posts in this series:

Welcome back for more dry philosophical musings (I promise there will be an actual working GUI with checkboxes and stuff in the next part). By the way, the code is here: github.com/danielearwicker/eventless/. Also note that I just realised that Getable and Setable would make more sense in a C# context than Readable and Writeable, so I’ve done some renaming.

Last time we got as far as defining a class that could hold a single value in a property called Value, and would fire an event called Changed whenever the value was modified.

Minor detour: for ultimate convenience let’s make a static helper method so we can take full advantage of the type inference that kicks in for generic methods but is sadly absent for constructors of generic classes:

public static class Setable
{
    public static Setable<T> From<T>(T initVal)
    {
        return new Setable<T>(initVal);
    }
}

Now we can really ramp up the hysteria as we add two numbers together:

var i = Setable.From(3);
var j = Setable.From(4);
var sum = Computed.From(() => i + j);

Now, I know it’s exciting but try to contain yourself. The point is, if (and only if) we modify i or j, we need sum to be recomputed (and thus in turn trigger recomputation of anything that consumes sum), just like it would be if these were cells in Excel. This will give us simplicity combined with optimal (that is, minimal) computation. When these are no longer integers but instead complicated data structures or large pieces of UI, it should seem a lot more useful.

So there has to be some magic plumbing involved that notices that we refer to i and j in our definition of sum.

First, Computed.From is just another handy static helper method:

public static class Computed
{
    // Excerpt...
    public static Computed<T> From<T>(Func<T> compute)
    {
        return new Computed<T>(compute);
    }
}

No surprises there, so let’s take a look at the more substantial generic Computed<T> class:

public sealed class Computed<T> : Forwarder<Setable<T>, T>, IGetable<T>, IDisposable
{
    private readonly Func<T> _compute;

    private ISet<IGetable> _subscriptions = Computed.EmptySubscriptions;

    public Computed(Func<T> compute)
        : base(new Setable<T>())
    {
        _compute = compute;
        Recompute();
    }

    private void Recompute()
    {
        var newSubscriptions = new HashSet<IGetable>();

        Computed.Listeners.Push(o => newSubscriptions.Add(o));
        var newVal = _compute();
        Computed.Listeners.Pop();
        Impl.Value = newVal;
        newSubscriptions.Remove(this);
        newSubscriptions.Remove(Impl);

        foreach (var sub in _subscriptions.Where(s => !newSubscriptions.Contains(s)))
            sub.Changed -= Recompute;
        
        foreach (var sub in newSubscriptions.Where(s => !_subscriptions.Contains(s)))
            sub.Changed += Recompute;
        
        _subscriptions = newSubscriptions;
    }

    public T Value
    {
        get { return Impl.Value; }
    }

    public void Dispose()
    {
        foreach (var sub in _subscriptions)
            sub.Changed -= Recompute;
    }
}

First key point: it only implements IGetable, not ISetable, so it has no setter for the value. This makes sense because it holds its own definition of what the value should be at any given moment.

Second (and this is really another detour), it kinda-sorta inherits from Setable, because it needs exactly the same kind of logic for triggering the Changed event only if the new value really is different. But I didn’t want to use full implementation inheritance, because then the features of Setable (such as the Value setter) would all be public, which we’ve already established doesn’t make sense. So instead I inherit a class called Forwarder, specifically designed to encapsulate an implementation of IGetable for the purposes of reuse. We’ll skip over the details of that, but basically if you’re familiar with private inheritance in C++, I’ve roughly simulated that. The end result is that we have a property Impl that holds the Setable we created in the base constructor call, and its Changed event is exposed for us.

Third: the meat of the class lies in its management of a set of other observables to which it subscribes for the Changed event. The currently subscribed observables are held in the _subscriptions set. The constructor calls Recompute the first time, and then Recompute has to make subscriptions so it will be called in the future, like this:

sub.Changed += Recompute;

The cunning part is this:

var newSubscriptions = new HashSet<IGetable>();

Computed.Listeners.Push(o => newSubscriptions.Add(o));
var newVal = _compute();
Computed.Listeners.Pop();
Impl.Value = newVal;

Remember that mystery call to Computed.Listeners.Notify(this) we encountered in part 1? Of course you do – you’ve been barely able to sleep for thinking about it constantly. Really, you look terrible. Just read the rest of this part and then try to get some rest.

Computed.Listeners is just defined as:

internal static readonly ListenerStack<IGetable> Listeners = new ListenerStack<IGetable>();

And ListenerStack is quite a handsome young utility class:

public class ListenerStack<T>
{
    private readonly ThreadLocal<Stack<Action<T>>> Stack =
                    new ThreadLocal<Stack<Action<T>>>(() => new Stack<Action<T>>());

    public void Push(Action<T> listener)
    {
        Stack.Value.Push(listener);
    }

    public void Pop()
    {
        Stack.Value.Pop();
    }

    public void Notify(T obs)
    {
        if (Stack.Value.Count != 0)
            Stack.Value.Peek()(obs);
    }
}

It allows us to notify (pass some value of some type or other) to the top-most listener in a stack of listeners on the current thread. The thread detail is something that knockout.js doesn’t have to worry about, but in the CLR it’s a must. If your UI thread is using Eventless and meanwhile some background worker has also found a use for it, they better not get their wires crossed. It would be a fine mess if the user of a library is careful not to share non-thread-safe objects (such as Setable) between threads, and then the library gets them tangled up anyway.

Computed registers its own listener at the top of the stack of listeners, which is a delegate that just records all the Getables that are notified about. And (as we saw in part one), Getables notify about themselves whenever their values are accessed.

So this means that Computed can (and does) easily find out exactly what Getables are read during the execution of its definition. It can then subscribe to them. In fact by using a HashSet it can pretty rapidly track any changes in its immediate dependencies. And they can be read anywhere while the definition is executing – way down the stack in some other method, without any need to explicitly pass any extra parameters around. The implications of that for constructing software are, I think, rather mind-blowing, and if your mind isn’t blown to smithereens by it, then either (a) you don’t fully get the implications yet, or (b) your mind is already in smithereens from previously discovering this.

One little bit of extra housekeeping:

newSubscriptions.Remove(Impl);

Rationale: it can be handy for a computed to read its old value, and while the definition delegate is executing that old value is there to be read, so we may as well allow it. But doesn’t make sense for it to consequently be dependent on itself.

Bonus Content

The other thing that will be very handy is a collection class. The idea is that (in part 3) we’re going to be displaying the contents of the collection in the UI, so it should be an ordered collection. So, not an ISet or an IDictionary. It must be possible to modify it through random access. In other words, it’s an IList. The CLR has an ObservableCollection class, but I’d like to start with a plain interface and build up from there (that way, it will be easy to bridge to any other frameworks):

public interface ISetableList<T> : IGetable<IList<T>>, IList<T>
{
    event Action<int> Added;
    event Action<int> Updated;
    event Action<int> Removed;
    event Action Cleared;
}

The events that take an int refer to the index within the collection. Note that the collection itself is an IGetable, not an ISetable – you can’t substitute in a new list. You have to clear it down and add new elements. This is no great hardship and simplifies a few things. But it is (effectively) a list of Setables, because you can update individual elements, hence the name ISetableList.

It is also an IList of the given element type. So in our implementation, SetableList, we have to implement all the methods of IList and make them trigger the appropriate events. And of course, whenever the value of an element is read, we better notify the Computed on the top of the stack (if any). Look at the code on Github for the details. for the details.

Okay, so we have most of the building blocks in place. Thank you for your patience. Next stop, part 3 and a working UI

Categories: Uncategorized Tags: , ,

Eventless Programming – Part 1: Why the heck?

February 25, 2013 10 comments

Posts in this series:

An “event” is a list of routines that all get executed (in unpredictable order) whenever something occurs. It is the low-level building block of complex interactive software.

But as abstraction, it fits poorly with our needs. Rather than the abstract idea of an event occurring, it is far more useful to think more specifically of a value changing. That is, we should always pair together two things: storage for a unit of information, and the event that the information has changed. This pairing is an observable.

In Windows Forms this pattern occurs, but only informally. For example, controls have a property called Enabled, and a corresponding event called EnabledChanged. Many controls have a property called Text, and an event called TextChanged. And so on. Unfortunately nothing links these together apart from the naming pattern.

WPF/Silverlight tried to fix this through Dependency Properties. A dependency property has a value, and there is a standard mechanism for notifying of a change in that value. But the results aren’t pretty: essentially it is just more manual event firing and handling, leading people to cook up various complex techniques to avoid writing so much boilerplate code.

There is a basic difficulty that occurs with stateful software. In mathematics once a value is defined and given a name, we don’t change it some time later on in the proof. In most programming languages that rule is tossed out carelessly. If x is said to be 5 and y is said to be x + 5, then y is surely 10… until x changes. Of course we could define y as a function of x, and recompute it every time we need to know the value, but in real programs we soon find that we’re repeating a lot of identical calculations, so instead we cache our values in variables, and then try to figure out manually when it would be an appropriate time to recompute them.

Events are the way we do this, but it’s crazy because we are repeatedly building, by hand, something that should be happening automatically, as simply as it does in Excel. If you put a 5 in cell B3 and then in another cell you put =B3+5, the spreadsheet is smart enough to know that it will need to recompute the second cell whenever the value in B3 changes. Excel gives us a model for declaring what our variables should contain, expressed in terms of other variables, and it harnesses the power of events to keep everything consistent, but we as users never have to manually hook up a single event handler, and nor should we.

Brothers and sisters, let us, here and now, build a C# framework for providing us with the convenience and minimal recomputation of Excel, but with the considerable advantage that we get to define the UI ourselves (and specify our own meaningful variable names instead of unhelpful cell references…)

(By the way, if you’re familiar with knockout.js, this is all going to seem eerily familiar, but a lot more statically typed.)

Now, buried beneath whatever we cook up, we will need an event. Let’s see how far we can get with a single solitary event doing all the work.

public interface IGetable
{
    event Action Changed;
}

[Sidenote: I was going to call it IObservable but as Brandon Wallace pointed out in the comments, there's already System.IObservable. Then I called it IReadable, but then I realised properties have getters and setters, and as you'll see, we're really just building an abstraction over a property with a Changed event.]

I’m breaking the rules of the event pattern by using the super-bland Action delegate, but I don’t care. A basic principle here is that Changed will never need to provide any further information about the event, other than the fact that it has occurred. By the way, that interface is already finished! I’m not going to add anything more to it, ever.

Well, kind of. It is just a base for us to extend:

public interface IGetable<out T> : IGetable
{
    T Value { get; }
}

This turns out to be very useful because it means from an event-handling perspective we can treat all observables alike, regardless of what type of value they hold. And again, we’re entirely done with that interface. It’s already being all it will ever need to be. Note that we only have a getter for the value, however. Which leads us to:

public interface ISetable<T> : IGetable<T>
{
    new T Value { get; set; }
}

All very pretty and abstract, but still no code that does anything. Patience, I’m building to it. Good grief, this is only part 1! Seriously, don’t you ever shut up? Alright, alright, here’s our first class, the actual implementation of an observable:

public sealed class Setable<T> : ISetable<T>, IEquate<T>
{
    private T _value;
    private bool _changing;

    public Setable(T value = default(T))
    {
        _value = value;
        EqualityComparer = DefaultEqualityComparer;
    }

    public T Value
    {
        get
        {
            Computed.Listeners.Notify(this);
            return _value;
        }

        set
        {
            if (EqualityComparer(_value, value))
                return;

            if (_changing)
                throw new RecursiveModificationException();

            _value = value;

            var evt = Changed;
            if (evt == null) 
                return;

            _changing = true;
            try { evt(); } 
            finally { _changing = false; }
        }
    }

    public event Action Changed;

    public Func<T, T, bool> EqualityComparer { get; set; }

    public static bool DefaultEqualityComparer(T a, T b)
    {
        return ReferenceEquals(a, b) || (!ReferenceEquals(a, null) && a.Equals(b));
    }

    public static implicit operator T(Setable<T> from)
    {
        return from.Value;
    }
}

It fully implements ISetable – not especially hard to do. The critically important part is that the Value property setter doesn’t fire the event unless the value has truly changed.

[Update: In the comments Mark Knell mentioned the problem of re-entrance. The check for equality before firing the event is a partial solution to that; it silently allows recursive attempts to set Value to the same value it already holds, without triggering a further event, and so endless unnecessary ping-ponging events are eliminated. But originally I also allowed recursive modification of Value during the firing of Changed, in mimicry of Knockout.js. As an experiment, I'm going ban this outright. Hence the _changing field, which is true while the exception is being fired. If Value is genuinely modified again while Changed is firing, that suggests a problem has arisen in the way events have been wired up. So a "Please don't do that" assertion seems called for. End of update]

Everything else in the class is about allowing you to supply an alternative way to compare values for equality. That other interface IEquate is part of that stuff, and is only there to support some generic constraints that aren’t particularly important:

public interface IEquate<T>
{
    Func<T, T, bool> EqualityComparer { get; set; }
}

The only puzzle here is that call to Computed.Listeners.Notify(this) in the Value getter. How can it be that a getter needs to do any notification? To see why that is, we’ll have to start trying to build support for computed observables, in part 2

Categories: Uncategorized Tags: , ,
Follow

Get every new post delivered to your Inbox.