This time I’ll show you an object-oriented version (a Life class) along with some other tweaks to make things look nicer.
You may have heard that mathematician John Conway died last April. To his everlasting dismay, most people only know him for his “game” of Life (which he considered trivial and inferior to his real mathematical work). Unfortunately for Conway, his Life game is fascinating.
To honor his passing, I whipped up a Python version that I thought I’d share. Python is about the only language I’ve used a lot in which I’ve never implemented Life, so high time I did, right?
Last time I began exploring Python decorators, which are a way of having one function “wrap” another function. Because the wrapper has access to both the input parameters and the return value, it can modify these values (unbeknownst to the inner function).
This time I pick up where I left off by exploring decorators modifying return values, decorators that take parameters, and decorators in classes.
I’ve been playing around with what Python calls decorators. They’re a built-in way of implementing Aspect-Oriented Programming techniques in Python. In fact, they’re quite powerful.
Since they aren’t a common language feature, they can be a little confusing at first, so I thought I’d try my hand at laying out how they work.
I saw a video recently about function currying, and it triggered the realization that currying might solve a problem I’ve been pondering in the context of language parsing. The problem involves knowing how many arguments an operator expects, what’s called the arity of an operation or function. It can vary from zero to many.
But it occurred to me that, with currying, there could be a language where operations always take just one argument. And that would solve a challenge for a mathematical expression language I have in mind.
Enough stories, time for a new rule. Which is to always use parentheses in all except the simplest of math expressions. Languages have a precedence protocol, so the compiler can figure it out, but human readers may be confused.
As always, the underlying motivation involves code clarity for other humans reading the source code — the most important rule of all.
Last time I introduced the DataCollector application, but didn’t have room to get into the use of factory classes. There isn’t often a need for a factory class, but they can be useful when you need to create objects at run-time without knowing their class until then.
The general approach involves a function that returns instances of a class based on run-time information. In some cases the instances are limited to a predetermined set of classes, in other cases it can any class the known to the code.
When I first posted about my DataBridge utility I mentioned the DataCollector, which was a Java-based framework for quickly building apps that interacted via web services with a third-party CRM services provider.
In this post I’ll introduce the DataCollector framework. For obvious proprietary reasons, this will be fairly generic, but I think the basic architecture is worth sharing. It’s a nice example of using factory classes.
Last time I started the story of my DataBridge application — a Java-based tool for transferring and transforming tabular data, such as TAB, CSV, and XML files. It could also read from and write to ODBC tables.
The app itself was just a framework that implemented a basic IPO model to transfer data. The details were up to the Input, Process (in this case, Mapping), and Output, drivers loaded at run time.