Stateful Programming - a key element

By Asaf Shelly (18 posts) on April 30, 2009 at 8:24 am

A key feature of Object Oriented Programming is code manageability and reusability, key feature of Procedural Programming is flow manageability. A key element in flow manageability is Stateful Programming. This methodology is very common with Procedural programmers and is very uncommon with Object Oriented programmers, but it is easily applicable.

I have recently decided to publish all of my code samples on my website: http://asyncop.com/Link.aspx?Open-Source. This may take a long while and is an ongoing process but every process starts with a first step. The first step here was to write a tool that could parse C\++\# source code and convert it into readable HTML format. This website is about parallel computing so I have decided to hit two birds with one stone and I wrote a code parser in a way which proves a technological principle and the first project I published with this parser was the source code for the parser itself.

The parser is written in C# which means that it is fully Object Oriented in programming and in design. I also applied the principles of Stateful Programming to the code and design so the code doesn't look like an academic OOP code.

The source code can be found here: http://asyncop.com/MTnPDirEnum.aspx?treeviewPath=%5bo%5d+Open-Source%5cProject+Publisher.
As you will immediately notice, this is not academic OOP because functions here are not limited to 3 - 4 lines of code. Instead you will find long functions and very small objects.

At the base of this parser is the need to go over a long string of text and parse it. Going over the characters one by one, some parts are dependant only on the selected character (such as ':'), others are dependant on previous characters (number after number / after letter), and some are character block definitions (such as #, ", /*, //, etc.). There is also a higher lexical analysis - identifying reserved words.

There is another important feature to the parser. It is higher level parsing such as locating classes and functions, finding class names and tagging them and so on (at the time this post is published the tagging feature is not yet published).

Procedural programmers use a term called state while parsing a long buffer. During the pass over the buffer the application's state-of-parsing changes. This brought on some of the coding constraints of the C language. One of the important features of this language was to make it simple for parsing when going forward on the buffer with a state-machine mechanism.

In the code you will widely see the use of such states. Actually most of the code is just the definitions of the different states, the detection of the states, and states dependencies. Actually to allow simple and flexible parsing capability I had to give up on state-object inheritance and thus all objects that define states are of the same type.

Actually there are more than one type of state: There is the state of character parser and there is the state of the higher level parser - who's job is to detect class names and function names and tag them. These state are not of the same type because they are completely asynchronous to each other. It is possible for a letter or a number to be part of a class, a function, or global, and it is also true for '#', '{', '}', and so on.

This is how Procedural Programming worked for a very long time. Object Oriented Programming however managed states using the stack. When we detect a new state we go into a new function. If you want to know the state of your application then you need to follow the stack trace. This is very very bad and terrible because it means that there is a single application-wide state. The state of the execution flow of the process using the stack is also the state of the business logic, and we have already determined that the business logic may have and maintain more than a single state at the same time. True as it may be - programmers do manage to parse protocols using academic OOP but most of the times it is due to intuition and step-by-step debugging. This is by no means a good programming following a robust design.

The parser I published works. This is the fifth version (currently it marks braces). Every addition to the parser was simple and strait forward without touching the original design, only adding to it.

Would you have used this type of object oriented programming?

Categories: Open Source, Parallel Programming, Software Engineering

Comments (0)

Trackbacks (5)


Leave a comment  

To obtain technical support, please go to Software Support.
Name (required)*

Email (required; will not be displayed on this page)*

Your URL (optional)


Comment*