Angel \”Java\” Lopez on Blog

April 25, 2016

Building A Blockchain (6)

Previous Post

These days, I added transaction processing to my personal project:

https://github.com/ajlopez/BlockchainSharp

In the previous post, I described the immutable Trie structure. Now, I have an AccountState that is saved by hash in a such Trie:

public class AccountState
{
    private BigInteger balance;

    public AccountState(BigInteger balance)
    {
        if (BigInteger.Compare(BigInteger.Zero, balance) > 0)
            throw new InvalidOperationException("Invalid balance");

        this.balance = balance;
    }

    public BigInteger Balance { get { return this.balance; } }

    public AccountState AddToBalance(BigInteger amount)
    {
        return new AccountState(BigInteger.Add(this.balance, amount));
    }

    public AccountState SubtractFromBalance(BigInteger amount)
    {
        return new AccountState(BigInteger.Subtract(this.balance, amount));
    }
}

I decided to implement the Ethereum way: having an account state, instead of inputs and outputs. The only property is Balance, but I will add more data. Notice that negative balances are rejeceted. Then, I added a TransactionProcessor:

public class TransactionProcessor
{
    private Trie<AccountState> states;

    public TransactionProcessor(Trie<AccountState> states)
    {
        this.states = states;
    }

    public Trie<AccountState> States { get { return this.states; } }

    public bool ExecuteTransaction(Transaction transaction)
    {
        var states = this.states;

        try
        {
            foreach (var av in transaction.Inputs)
            {
                var addr = av.Address.ToString();
                var state = states.Get(addr);
                var newstate = state.SubtractFromBalance(av.Value);
                states = states.Put(addr, newstate);
            }

            foreach (var av in transaction.Outputs)
            {
                var addr = av.Address.ToString();
                var state = states.Get(addr);
                var newstate = state.AddToBalance(av.Value);
                states = states.Put(addr, newstate);
            }

            this.states = states;

            return true;
        }
        catch (Exception ex)
        {
            return false;
        }
    }
}

If the transaction is processed, a new account state trie is generated, and ExecuteTransaction returns true. If the transaction is rejected, the initial accout state trie still has the original values. A typical test:

[TestMethod]
public void ExecuteTransaction()
{
    var transaction = CreateTransaction(100);

    var addr1 = transaction.Inputs.First().Address;
    var addr2 = transaction.Outputs.First().Address;

    var states = new Trie<AccountState>(new AccountState(BigInteger.Zero));

    states = states.Put(addr1.ToString(), new AccountState(new BigInteger(200)));

    var processor = new TransactionProcessor(states);

    Assert.IsTrue(processor.ExecuteTransaction(transaction));

    var newstates = processor.States;

    Assert.IsNotNull(newstates);
    Assert.AreNotSame(states, newstates);

    Assert.AreEqual(new BigInteger(200), states.Get(addr1.ToString()).Balance);
    Assert.AreEqual(BigInteger.Zero, states.Get(addr2.ToString()).Balance);

    Assert.AreEqual(new BigInteger(100), newstates.Get(addr1.ToString()).Balance);
    Assert.AreEqual(new BigInteger(100), newstates.Get(addr2.ToString()).Balance);
}

The auxiliary CreateTransaction method creates a transaction with an amount, and two random addresses.

I’m thinking to have only one sender account and receiving account per transaction, as in Ethereum. The change is easy, I have all the TDD tests to help me to do redesigns without a lot of work.

Next topics: executing blocks with transactions, saving state in persistent store, virtual machine and its bytecodes, a simple compiler, etc…

Stay tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

April 17, 2016

Building A Blockchain (5)

Filed under: Bitcoin, Blockchain, C Sharp, Ethereum, Test-Driven Development — ajlopez @ 10:02 am

Previous Post
Next Post

I was working a lot on my personal project:

https://github.com/ajlopez/BlockchainSharp

implementing a blockchain in C#, using TDD (Test-Driven Development) workflow. One element I need to implement, is the store of account states (initially their balances). The balance of an account should be retrieved by account id (a hash). But in many use cases, I need to know the balances of accounts at a given time. It is not enough to have the LATESTS balances. So, I implemented a data structure, a trie, but with immutable properties.

A trie is a tree where the non-leaf nodes stores part of the key:

In the above example, the value V1 is associated with key AAA, and the value V5 is associated with key ACA. When I change the value associated with key ABC from V4 to V7, part of a new trie is created, so the original one persists without modification:

I can access the original key/values using the “old root”, and then, I can switch to use the “new root”, at any moment. If any node/root is not reachable from a variable, garbage collector will release the memory associated with that node.

I wrote a typed trie implementation, using TDD. An example test:

[TestMethod]
public void PutAndGetKeyValue()
{
    Trie<string> trie = new Trie<string>();

    var trie2 = trie.Put("012", "foo");

    Assert.IsNotNull(trie2);
    Assert.AreNotSame(trie2, trie);
    Assert.IsNull(trie.Get("012"));
    Assert.AreEqual("foo", trie2.Get("012"));
}

An example that shows the persistent of tries after updates:

[TestMethod]
public void ReplaceValue()
{
    Trie<string> trie = new Trie<string>();

    var trie2 = trie.Put("012", "foo");
    var trie3 = trie2.Put("012", "bar");

    Assert.IsNotNull(trie2);
    Assert.AreNotSame(trie2, trie);
    Assert.IsNull(trie.Get("012"));
    Assert.AreEqual("foo", trie2.Get("012"));

    Assert.IsNotNull(trie3);
    Assert.AreNotSame(trie3, trie2);
    Assert.AreEqual("bar", trie3.Get("012"));
}

My idea is to use Trie<AccountState> as a store for account balances. At the end of a block (with transactions) processing, there is an account state trie. Ant the end of the next block processing, another trie will be generated. At any moment, I could retrieve the account balances at time “block 1”, and at time “block 2”, using the generated tries.

Stay tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

April 4, 2016

Building A Blockchain (3)

Previous Post
Next Post

I added a lot of code to my simple blockchain implementation written in C#:

https://github.com/ajlopez/BlockchainSharp

As usual, I followed TDD (Test-Driven Development) workflow, pursuing simplicity, doing baby steps. In the last post I mentioned the use of a DSL (Domain Specific Language) to specify some block processing tests that have complex setup.

Initially, I wrote tests like:

[TestMethod]
public void ProcessTwoBlocksAndTwoUncles()
{
    Block genesis = new Block(0, null);
    Block block = new Block(1, genesis.Hash);
    Block uncle1 = new Block(1, genesis.Hash);
    Block uncle2 = new Block(2, uncle1.Hash);

    BlockProcessor processor = new BlockProcessor();

    processor.Process(genesis);
    processor.Process(block);
    processor.Process(uncle1);
    processor.Process(uncle2);

    Assert.IsNotNull(processor.BlockChain);
    Assert.AreEqual(2, processor.BlockChain.BestBlockNumber);
    Assert.AreEqual(genesis, processor.BlockChain.GetBlock(0));
    Assert.AreEqual(uncle1, processor.BlockChain.GetBlock(1));
    Assert.AreEqual(uncle2, processor.BlockChain.GetBlock(2));
}

The idea is:

– Create some blocks

– Send the blocks to the block processor

– Check the blocks in the block chain

The created blocks are related by parent relationships. Sometimes, a competing block is created, so the block processor must deal with block branches.

But the setup code could be long and complex. So, I wrote a DSL, and now I have tests like:

[TestMethod]
public void SendTwoBlocksAndTwoUncles()
{
    var processor = new BlockProcessor();
    var dsl = new BlockProcessorDsl(processor);

    dsl.Run(new string[] 
    {
        "chain g0 b1 b2",
        "chain b1 c2 c3",
        "send b1 b2",
        "send c2 c3",
        "top c3"
    });
}

Each command is an string, with verb and arguments. The block g0 is the genesis block. The verb “chain” enumerates a list of blocks to be created, each block is child of its previous block. The verb “send” sends the created blocks to the block processor. The verb “top” checks if the specified block is the top block in the current blockchain.

The result should not depend on order of arriving blocks, ie:

[TestMethod]
public void SendTwoBlocksInReversedOrder()
{
    var processor = new BlockProcessor();
    var dsl = new BlockProcessorDsl(processor);

    dsl.Run(new string[] 
    {
        "chain g0 b1 b2",
        "send b2 b1",
        "top b2"
    });
}

I could add text files, each one specifying command lines to be executed as sentences of the DSL.

In the next posts: core implementations needed by a blockchain, byte serialization, and implementing immutable tries for storing states.

Stay tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

March 28, 2016

Building A Blockchain (2)

Previous Post
Next Post

In the past days, I wrote a first implementation of a blockchain, using TDD (Test-Driven Development). Simplicity guides my decision: the blockchain is in-memory, and blocks are identified by number and a hash. Two blocks with number 42 are differente blocks if they have different hashes. A block has the parent block hash (the parent block number is deduced, it’s the block number minus one). A genesis block has number 0, and null parent hash. In this way, I have all the ingredients to build a blockchain, from genesis block to best block, chaining the blocks using their numbers and hashes.

I have a class BlockChain (yes, I prefer the mixed case name). There is a method to add a new block to the blockchain. It controls the new block has as parent the current best block in the blockchain.

But there are other nodes, that send other blocks, that can or cannot be added to the blockchain. How to process those blocks? I collect the blocks that cannot be added to the current blockchain in other objects, I call them blockbranch:

In the second blockbranch, parent block for block 41 is unknown, so, the blockbranch is waiting for the arrival of that block. The first blockbranch is connected to blockchain, as an alternative branch. But is has a height less than blockchain height.

A block branch has one or more consecutive blocks. The blocks are not part of the current blockchain. But they are proto-blockchain.

In the second blockbranch of the above figure, parent block for block 41 is unknown, so, the blockbranch is waiting for the arrival of that block. The first blockbranch is connected to blockchain, as an alternative branch. But is has a height less than blockchain height.

When I have sufficient blocks in a block branch (maybe, connect the bottom of the blockbranch to an existing block in another blockbranch or in the current blockchain), and I can build a list of blocks from genesis to the block in block branch, the branch is a candidate to be the new blockchain. Suppose a new block arrives:

The new block can be added to the second block branch, and it has an existing parent in the current blockchain. So, the block branch now has a complete path of block from genesis.

If the block branch is valid (applying their blocks to a known valid state at end of main block 39), and its height is greater than the current blockchain, the block branch is promoted to be the new blockchain:

The process works even if the new blocks arrives in random order. To manage the creation, growth, and promotion of blockchain and related blockbranches, I have a separate object, of class BlockProcessor, in charge of all this orchestration. The processor receives the new blocks, and send them to the corresponding blockchain or branch. Then, it can detect any new connection between branches, and the formation of branches that can be promoted to blockchains.

In the next post: details of a DSL (Domain Specific Language) I’m using to test different scenarios for the block processor.

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

April 25, 2015

Liqueed Project (6)

Filed under: Express, JavaScript, Liqueed, NodeJs, Test-Driven Development — ajlopez @ 4:26 pm

Previous Post

Let review another tests from test/personapi.js in project:

https://github.com/liquid-co-ops/liqueed

There are API entrypoints that are called using PUT or POST. They receive data in the body of the sent message. Using Express middleware, that message (formatted as JSON) is analized, parsed and converted into a JavaScript object. That object resides in the body property of the received request parameter. As the API uses that field, we should provide it in the test. An example:

exports['login person'] = function (test) {
    test.async();
    
    var request = {
        body: {
            username: persons[1].username,
            password: persons[1].username
        }
    };

    var response = {
        send: function (model) {
            test.ok(model);
            test.equal(model.id, persons[1].id);
            test.equal(model.name, persons[1].name);
            test.equal(model.username, persons[1].username);
            
            test.done();
        }
    };
    
    controller.loginPerson(request, response);
};

As in the previous example, we use the send function in the response object, to check the result.

Another example, sending not only the body but also sending parameters:

exports['change password first person'] = function (test) {
    test.async();
    
    var request = {
		params : {
			id : persons[0].id.toString()
		},
        body: {
            password: 'new' + persons[0].username
        }
    };

    async()
    .then(function (data, next) {
        var response = {
            send: function (model) {
                test.ok(model);
                test.strictEqual(model, true);
                
                next(null, null);
            }
        };
        
        controller.updatePassword(request, response);
    })
    .then(function (data, next) {
        var request = {
            body: {
                username: persons[0].username,
                password: 'new' + persons[0].username
            }
        };

        var response = {
            send: function (model) {
                test.ok(model);
                test.equal(model.id, persons[0].id);
                test.equal(model.name, persons[0].name);
                test.equal(model.username, persons[0].username);
                
                test.done();
            }
        };
        
        controller.loginPerson(request, response);
    })
    .run();
};
 

Next posts: MVC controller actions tests, tests launching the HTTP server, tests using a DSL (Domain-Specific Language)

Stay tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

April 20, 2015

Liqueed Project (5)

Filed under: Express, Liqueed, NodeJs, Test-Driven Development — ajlopez @ 5:38 pm

Previous Post  
Next Post

Let review two more tests from test/personapi.js. The second test is actually:

exports['get persons'] = function (test) {
    test.async();
    
    var request = {};
    var response = {
        send: function (model) {
            test.ok(model);
            test.ok(Array.isArray(model));
            test.ok(model.length);
            test.ok(model[0].id);
            test.ok(model[0].name);
            test.done();
        }
    };
    
    controller.list(request, response);
};

After building the domain model in memory (the first test taks), now we can test a controller action method, named getPersons. It requires to receive two arguments, request and response object. In the above code, two stubs were built and used. The response object has a send function that  it should be invoked to pass the tests. It receives the model to send to the client, as a JavaScript object (in the real environment, the object is serialized to JSON via Express response send method).

The third test is:

exports['get first person'] = function (test) {
    test.async();
    
    var request = {
        params: {
            id: persons[0].id.toString()
        }
    };

    var response = {
        send: function (model) {
            test.ok(model);
            test.equal(model.id, persons[0].id);
            test.equal(model.name, persons[0].name);
            test.done();
        }
    };
    
    controller.get(request, response);
};

The action needs something from request object, an aditional argument having the person primary key to be retrieved. There is a send method in request object, to test the result.

The tests are not using HTTP nor GET method. They are directly testing the controller code. Indeed, that code was written AFTER the tests, and its first execution was from test launch, without the need of launch a web server.

Next posts: other tests for API methods, sending objects, and tests for MVC controllers

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

April 15, 2015

Liqueed Project (4)

Filed under: Express, JavaScript, Liqueed, NodeJs, Test-Driven Development — ajlopez @ 8:42 pm

Previous Post
Next Post

The project:

https://github.com/liquid-co-ops/liqueed

was built using TDD (Test-Driven Development) worflow. In the previous post I showed a logic service example, implemented using tests. Today, I want to show that the MVC controllers was also coded using TDD. The controllers are JavaScript modules that expose functions as actions to be routed by Express. The actions receive and return JSON objects. They are the basis for the exposed API, to be consumed by the clients (actually, only one client, a simple single page application). For example, controllers\personapi.js starts declaring:

'use strict';

var service = require('../services/person');

It consumes the person service module.

There are associated test at test\personapi.js, its initial imports:

'use strict';

var controller = require('../controllers/personapi');

var loaddata = require('../utils/loaddata');
var db = require('../utils/db');
var async = require('simpleasync');

In the previous post, I mentioned that the test granularity I prefer for JavaScript is the module, not the function. So, all the tests in the module are execute, in declaration order. The first test is in charge of inicialization the domain model:

var persons;

exports['clear and load data'] = function (test) {
    var personService = require('../services/person');

    test.async();
    
    async()
    .then(function (data, next) { db.clear(next); })
    .then(function (data, next) { loaddata(next); })
    .then(function (data, next) { personService.getPersons(next); })
    .then(function (data, next) {
        persons = data;
        test.ok(persons);
        test.ok(persons.length);
        test.done();
    })
    .run();
};

The new thing to understand is the use of the module simpleasync, pointed by the async variable. I wrote the module to chain  functions. Each function receives two arguments: data, the success result of the previous executed function in chain, or the initial value triggered in the run chain function. And next, a callback to be invoked by the function, to execute the rest of the chain. The callback receives two arguments: err and data. So it can be used as the callback of other functions. If err is not null, the next functions in chain is not executed and the function defined in the chain fail method is run (this option is not used in the above code). In the above example  personService.getPersons(next) invokes the retrieve of the person list, using next as callback. The next chained function receives the person list in the data argument, and then, it saves it in a module variable, ready to be used by the rest of the tests.

It is not using a database. It using an in-memory domain model. That is the default “persistence”, and it is used in many of the defined tests. The initial domain model is loaded from testdata.json using the loaddata function:

{
    "projects": [
        {
            "name": "FaceHub",
            "periods": [
                { 
                    "name": "January 2014", 
                    "date": "2014-01-31", 
                    "amount": 100,
                    "assignments": [
                        { "from": "Alice", 
                            "to": "Bob", 
                            "amount": 50, 
                            "note": "Arrive earlier" },
                        { "from": "Alice", 
                            "to": "Charlie", 
                            "amount": 50 , 
                            "note": "Arrive earlier" },
                        { "from": "Bob", 
                            "to": "Alice", 
                            "amount": 60 , 
                            "note": "Arrive earlier" },
                        { "from": "Bob", 
                            "to": "Charlie", 
                            "amount": 40 , 
                            "note": "Arrive earlier" },
                        { "from": "Charlie", 
                            "to": "Alice", 
                            "amount": 35 , 
                            "note": "Arrive earlier" },
                        { "from": "Charlie", 
                            "to": "Bob", 
                            "amount": 65 , 
                            "note": "Arrive earlier" }
                    ]
                },
                { "name": "February 2014", 
                    "date": "2014-02-28", 
                    "amount": 100 }
            ],
            "team": [ "Alice", "Bob", "Charlie" ],
//....

The module personapi.js exports some functions to be used as actions:

module.exports = {
    list: list,
    get: get,
    getProjects: getProjects,
    loginPerson: loginPerson,
    getPendingShareProjects:getPendingShareProjects,
    updatePassword: updatePassword
}

Topics for the next posts: more API tests, routing of actions, persistence, etc.

Stay tuned!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

March 18, 2015

Liqueed Project (3)

Filed under: Express, JavaScript, Liqueed, NodeJs, Test-Driven Development — ajlopez @ 5:24 pm

Previous Post
Next Post

I’m a big supporter of TDD (Test-Driven Development), and its workflow for software development. The software is created based on the tests that describe the expected behaviour, using the simplest possible implementation. For Liqueed Project, TDD was adopted during the creation of most of the code.

An example: there is a file, services\person.js, that is a JavaScript module. It manages the logic of the persons. A person can participate in zero, one or more projects, have sharepoints, vote, etc. And the system keeps the list of persons, retrieve a person by id, by username, … Part of the logic is in the service module. It was written using test/person.js for the tests of the logic. One test, one impementation, refactor, and so on. At the beginning of the test mode, there are some requires:

'use strict';

var service = require('../services/person');
var pservice = require('../services/project');
var async = require('simpleasync');

The services persons and project are used. simpleasync is a simple module I wrote to chaining callbacks. It was an interesting experience, and I’m doing “dog-fooding” in many projects.

Then, two module variables are declared, to be reused in the tests. They are the ids of some persons:

var annaid;
var lauraid;

To run the tests, I’m using simpleunit, another module I wrote, again, to practice JavaScript, TDD and simplicity. It is inspired by nodeunit, but it is simpler. simpleunit executes the module exported functions, providing a test object, something alike to assert in NodeJs.

The first tests exercises the creation of a person:

exports['add person'] = function (test) {
    test.async();

    service.addPerson({ name: 'Anna' }, function (err, result) {
        test.ok(!err);
        test.ok(result);
        annaid = result;
        test.done();
    });
};

It has a callback, so the function could end BEFORE the creation of the person. So, the test.async() tells to simpleunit to wait until the test.done() is reached. The above test only check the return of an id for the new person, and the value is saved in a module variable. This is something to discuss, but I found this way an easy one. The second tests depends on the first one. In C#, in other technologies, I wrote more isolated tests. But for me, in JavaScript, the level of isolation is the module, not the test function. In a module, a test function could depend on the execution of a previous one.

The second test:

exports['get person by id'] = function (test) {
    test.async();

    service.getPersonById(annaid, function (err, result) {
        test.ok(!err);
        test.ok(result);
        test.equal(result.name, 'Anna');
        test.equal(result.id, annaid);
        test.equal(result.username, 'anna');
        test.done();
    });
};

Using the id generated by the first test, the person is retrieved, and the data is checked.

This test series doesn’t use a predefined domain, and it does not assume a previous well-knoen status. And these tests are implemented using an in-memory domain. In the initial iterations, this in-memory domain was the only implementation. Only after the implementation of the first big use case, we added a domain persisted in MongoDB.

Stay tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

December 10, 2014

SimpleLisp (2) Compiling Lisp Values and Variables to JavaScript

Previos Post

Let’s review the project’s implementation

https://github.com/ajlopez/SimpleLisp

the Lisp compiler to JavaScript, written in JavaScript, following the workflow of TDD (Test-Driven Development). All is “work in progress”, so today I will explain part of the implementation but it could be change in the future, when new use cases were added, and new ways of doing things were implemented.

I took the decision that each Lisp symbol is a JavaScript variable. So, the compilation of a symbol is:

exports['compile symbol'] = function (test) {
    test.equal(sl.compile('a'), 'a');
}

The sl is the SimpleLisp module, loaded in this test file (test/compile.js)

An integer and an string are compiled to natural values in JavaScript:

exports['compile integer'] = function (test) {
    test.equal(sl.compile('42'), '42');
}

exports['compile string'] = function (test) {
    test.equal(sl.compile('"foo"'), '"foo"');
}

It’s quoted values, too:

exports['compile quoted integer'] = function (test) {
    test.equal(sl.compile("'42"), '42');
}

exports['compile quoted string'] = function (test) {
    test.equal(sl.compile("'\"foo\""), '"foo"');
}

I decided to compile Lisp nil to JavaScript null. The boolean values are the same:

exports['compile nil'] = function (test) {
    test.equal(sl.compile('nil'), 'null');
}

exports['compile booleans'] = function (test) {
    test.strictEqual(sl.compile('false'), 'false');
    test.strictEqual(sl.compile('true'), 'true');
}

But, what happens if an expression serie is compiled? I build an anonymous function, invoked without arguments, and the last expression value is returned:

exports['compile two symbols'] = function (test) {
    test.equal(sl.compile('a b'), '(function () { a; return b; })()');
}

Next topics: compilation of a Lisp lisp, and more quoted values, macros, ect.

Stay tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

November 28, 2014

SimpleScript (3) The Parser, Expressions and Commands

Previos Post

Let’s visit the Parser, that is a separated module. It starts with a simple declaration:

'use strict';

var lexer;

if (typeof lexer == 'undefined')
    lexer = require('./lexer');

var parser = (function () {
    var TokenType = lexer.TokenType;
    var binoperators = [ "+", "-", "*", "/", "==", "!=", "<", ">", "<=", ">=" ];

It uses and requires the lexer module. After this declaration, there are many expressions and commands. This is the expression “class” for a name (ie, foo):

function NameExpression(name) {
    this.isLeftValue = true;

    this.compile = function () {
        return name;
    };

    this.getName = function () {
        return name;
    }

    this.collectContext = function (context) {
        context.declare(name);
    }
}

In an upcoming post, I will describe the detection and construction of commands and expression. An expression should implement two methods: compile, that returns an string with the compiled JavaScript code associated to the expression, and collectContext, that allows the discover of used variables in an expression/command. In the above code, NameExpression declares its name to a context, an object that is recovering the used variables.

This is an IndexedExpression, composed by an expression and another one for the index (it’s like foo[42+1]):

function IndexedExpression(expr, indexpr) {
    this.isLeftValue = true;

    this.compile = function () {
        return expr.compile() + '[' + indexpr.compile() + ']';
    };

    this.collectContext = function (context) {
        expr.collectContext(context);
    }
}

The collectContext visits the internal expression (I could add the visit of the index expression, too).

There are commands, like IfCommand:

function IfCommand(cond, thencmd, elsecmd) {
    this.compile = function () {
        var code = 'if (' + cond.compile() + ') { ' + thencmd.compile() + ' }';
        if (elsecmd)
            code += ' else { ' + elsecmd.compile() + ' }';
        return code;
    };

    this.collectContext = function (context) {
        cond.collectContext(context);
        thencmd.collectContext(context);
        if (elsecmd)
            elsecmd.collectContext(context);
    }
}

The distinction between commands and expressions is a formal one. Again, a command should implement compile and collectContext. The above code generates a JavaScript if command.

As usual, I followed TDD (Test-Driven Development) workflow. Partial tests example:

exports['Compile string without quotes inside'] = function (test) {
    test.equal(compileExpression("'foo'", test), "'foo'");
    test.equal(compileExpression('"foo"', test), "'foo'");
}

exports['Compile name'] = function (test) {
    test.equal(compileExpression("foo", test), "foo");
}

exports['Qualified name'] = function (test) {
    test.equal(compileExpression("foo.bar", test), "foo.bar");
}

exports['Indexed term'] = function (test) {
    test.equal(compileExpression("foo[bar]", test), "foo[bar]");
}

Remember: No TDD, no paradise!😉

Next topics: how to recognize and build expressions and commands.

Stay tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

Older Posts »

The Shocking Blue Green Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 73 other followers