Thursday, September 15, 2011

Fantom: Constructors, Required Fields, and More

This post is part of a series of sorts where I write about what I find while exploring the Fantom language. This time I'm going to share what I find out about declaring and using classes as I go. I imagine I will only scratch the surface.

To give you the chance to devote some of your valuable reading time elsewhere, below is a summary of some of the highlights covered below:

  • Declaring class fields that are required at object creation and throughout the lifetime of the object
  • Default class field values
  • Automatic getters and setters

A class can be declared using the class keyword as we're all probably used to. Let's declare a (boring) class Person with a name field and add a main method so we can try and create an instance.

Assignments in Fantom are done via the use of := instead of an equals sign. Here we'll start by simply creating an empty object and printing out to the console that we've succeeded:

    class Person {
Str name

static Void main(Str[] args) {
Person p := Person()
echo("Person created.")
}
}

The variable p is given what looks to be the result of a call to a default constructor. We can run the above with:

   $ fan Person.fan

Our first run gives us the following error:

   Non-nullable field 'name' must be assigned in constructor 'make'

The error hints that the call to Person() results in a call to a constructor named make. Also, the error descrption seems to go against what we may be used to in Java, where class properties can be null. Right of the bat to me, this could demonstrate a potential strength of Fantom as, as given the class definition above, a user cannot create an incomplete Person. If we want to create a Person without assigning a value to the name field, we can append a '?' to the field declaration:

    class Person {
Str? name

static Void main(Str[] args) {
Person p := Person()
echo("Person created.")
}
}

This time we'll get the "success" message indicating we've created a Person. Let's keep the name field required and assign a value to it when the Person is constructed. To do this, we can add a constructor and in the main method create a Person named 'Cosmo':

    class Person {

Str name

new make(Str name) {
this.name = name
}

static Void main(Str[] args) {
Person p := Person("Cosmo")
echo("Person created with name: " + p.name)
}
}

As you can see, the main method now also reports the name of the created Person via a call to the name method. Although it looks like we are accessing the field directly, getters and setters are automatically created for each field which helps us cut down on the amount of boilerplate code our class might contain, not unlike some of the newer JVM langauges. Running things through the interpreter again gives us:

    Person created with name: Cosmo

To demonstrate the generated setter, we can add the following:

    p.name = "George"
echo("Person renamed to: " + p.name)

The output of our program is now:

   Person created with name: Cosmo
Person renamed to: George

One question I now have is now that we have declared the name field as non-null at construction time, can we assign the value to null after the object has been created? Let's add the lines below to the main method:

    p.name = null
echo("Person with null name?: " + p.name)

With the above in place, we now get an error:

   'null' is not assignable to 'sys::Str'

Again, this restriction should in practice help keep our class instances safe and remove the usual null-checking concerns.

Now some might say a class with one field might be pretty boring (if not useless). Lets add another field, age, but not require a user of the class to do a Person's age at construction time by allowing a default value (since age can be a touchy subject anyway). Let's try adding another constructor to be used when both the name and the age of the Person are known:

    class Person {

Str name
Int age := 1

new make(Str name) {
this.name = name
}

new make(Str name, Int age) {
this.name = name
this.age = age
}

static Void main(Str[] args) {
Person cosmo := Person("Cosmo", 40)
Person marshall := Person("Marshall")
echo("Person " + cosmo.name + ", aged " + cosmo.age)
echo("Person " + marshall.name + ", aged " + marshall.age)
}
}

Here will create two Persons with an declared age and one with the default of 1, and report on both:

    Duplicate slot name 'make'

Ah, we get an error... are we not allowed to have two constructors? Turns out in Fantom, constructors are treated like methods, with the new keyword out in front, and can be either be named make or start with make. Since we will likely prefer for our users to fully populate the class fields, let's name the two parameter constructor make and rename the original:

    new makeNamed(Str name) {
this.name = name
}

new make(Str name, Int age) {
this.name = name
this.age = age
}

Here though, how do we differentiate between which constructor is used for each assignment? The Persons we create are made through a call to Person(...)? Turns out we can call the constructors by name by referring to them through the class definition:

    Person cosmo := Person.make("Cosmo", 40)
Person marshall := Person.makeNamed("Marshall")

We cannot it appears make calls to Person(...) like we did before and have the compiler infer with constructor to use asin:

    Person cosmo := Person("Cosmo", 40)
Person marshall := Person("Marshall")

This results in the error:

   Invalid args (sys::Str, sys::Int), not (sys::Str)

Back to the explicit calls, our class now reads:

    class Person {

Str name
Int age := 1

new makeNamed(Str name) {
this.name = name
}

new make(Str name, Int age) {
this.name = name
this.age = age
}

static Void main(Str[] args) {
Person cosmo := Person.make("Cosmo", 40)
Person marshall := Person.makeNamed("Marshall")
echo("Person " + cosmo.name + ", aged " + cosmo.age)
echo("Person " + marshall.name + ", aged " + marshall.age)
}
}

Giving this attempt a shot gives us...

   Person Cosmo, aged 40
Person Marshall, aged 1

...output for both Persons, with the second making use of the default age.

This looks like enough to cover for now in one post. Looking at the documentation further, there's looks like there's a lot more to cover at a later date. If I find I misstated any of the terminology or made things more difficult then they need to be, I'll be sure to come back and make corrections.

Tuesday, September 13, 2011

Creating a Marco in Vim

I'm a fan of the vim text editor, and try to use it as much as possible. I have hard time though making the effort to learn more than I already know. While I think I can use it pretty effectively, I know I've truly only scratched the surface.

Often I find myself retyping the same commands over and over to repeatedly accomplish the same task. I then make a mental note to learn about creating macros, which would of helped me out. I then proceed to forget about immediately.

Not today though. Today I'm going to create my first macro.

A macro is a series of commands that can be replaced. Marcos can be assigned to buffers so they can be saved and recalled. Buffers have single- character names in the ranges:

  • 0-9
  • a-z
  • A-Z

To start the definition of a macro in command mode, type 'q' followed by a single character in one of the ranges above.

I'm going to start with the text below and think of some reason to create a macro:

hello my name is george
hello my name is george
hello my name is george

How about we try and replace every occurence with "name" with "first name". We could do a global substitution by typing a colon followed by 's/name/first name/g' and hitting enter, but I want to try out a macro.

A marco could simply:

  1. Search for the next occurrence of name.
  2. Replace "name" with "first name" (or insert the text "first ")

Let's try it out. With my cursor on the first character in the file, if I:

  1. Type 'q' to declare I want to define a macro
  2. Type 'a' to assign the macro to buffer 'a'
  3. Type '/' followed by "name" then Enter to find the first occurence of "name"
  4. Type 'cw' followed by "first name" then Esc to change the word
  5. Type 'q' to complete the macro definition

The text should now have one occurrence of "first name" in place of "name":

hello my first name is george
hello my name is george
hello my name is george

Now we can run the macro typing '@a'. Running it twice will complete the remaning two substitutions, giving us:

hello my first name is george
hello my first name is george
hello my first name is george

We could also run the marco a number of times with one command. Say, given the text above where the first substitution was done, if we wanted to run the marco twice in one shot, instead of invoking it two separate times, we can type '2@a'.

Thursday, September 8, 2011

Exceptions for Control Flow: Always Wrong?

It is generally accepted that exceptions should never be used for control of flow and should only be used for exceptional conditions. On face value, that assertion seems to make sense. For instance, given a method that iterates over an array, the user of the method should not be expected to catch a NoSuchElementException because the method does not make use of a hasNext() method.

If a state checking method is available to help determine if another method can be called, we would all assume it should be used. However, what about cases where a series of methods must be called in sequence to accomplish a larger overall task? In a scenario I'm thinking off, a series of individual methods must be called, where each in the sequence is called only if the previous call succeeded.

Would disobeying the exceptions rule possibly make for cleaner code in such a case?

To work out my thoughts, I thought of a home building example. Let's simplify building a house to three steps: laying a foundation, putting up the framing and walls, and then adding the roof.

Let's also imagine a contractor who's job is to build a house, ensuring its marked as condemned is any of the construction fails. If the contractor attempts to add the framing without the foundation, or the roof without the framing, a catastrophe would surely happen. To avoid the catastrophe, the builder must check the house to ensure the previous step completed before moving on to the next.

Like an Iterator with a hasNext() method, the House class has methods or state variables indicating whether it has the requirements for the next phase of construction and something similarly for its overall state: whether or not its livable or condemned.

    class House {
boolean hasFoundation
boolean hasFraming
boolean hasRoof
boolean isCondemned
}

The Contractor classs has one public method, buildHouse(), that returns a House, livable or not, and a private method for completing each step in the construction process:

    class Contractor {

public House buildHouse() {
def house = new House()

addFoundationTo(house)

if (house.hasFoundation) {
addFramingTo(house)
if (house.hasFraming) {
addRoofTo(house)
if (!house.hasRoof()) {
house.isCondemend = true
}
} else {
house.isCondemned = true
}
} else {
house.isCondemned = true
}

house
}

private def addFoundationTo(house) {
//...
}

private def addFramingTo(house) {
//...
}

private def addRoofTo(house) {
//...
}
}

This contractor is overly cautious as he wants to condemn the house as soon as possible if one of the constuction steps fails to avoid a catastrophe. Another implementation may wait till the building process is completed before condemning the house:

    class Contractor {

public House buildHouse() {
def house = new House()

addFoundationTo(house)

if (house.hasFoundation) {
addFramingTo(house)
if (house.hasFraming) {
addRoofTo(house)
}
}

if (!house.hasRoof()) {
house.isCondemned = true
}

house
}
}

This contractor only looks at the roof and the end of the process to determine if the house should be condemned, which may lead to a lawsuit if the someone where to change the order in which the steps were executed. The contractor's check at the end could include looking at the foundation and framing as well, but he is overly trusting of his workers not to proceeded and the extra checks may be costly.

What if a different contractor required a complaint be raised by a worker if any of the home building steps fails and condemns the house if he receives the complaint before attempting the next step?

    class Contractor {

public House buildHouse() {
def house = new House()

try {
addFoundationTo(house)
addFramingTo(house)
addRoofTo(house)
} catch (ConstructionComplaint complaint) {
house.isCondemned = true
}

house
}

private def addFoundationTo(house) throws ConstructionComplaint {
//...
}

private def addFramingTo(house) throws ConstructionComplaint {
//...
}

private def addRoofTo(house) throws ConstuctionComplaint {
//...
}
}

Here, a specific, but uniform, exception is given to the builder if any of the steps fail, ensuring the next step in the process is not attempted, avoiding a catastrophe.

An argument for this procedure may include that adding another step, like adding a garge, does not increase the complexity of the building process by adding more evaluation (branching), or require the builder to explicitly check that a garge can be added. Conversely, this approach may be overly trusting in that it requires a each worker method properly files a complaint.

I think it's safe to say we've all seen complex code as least as complex as the first implentation of the buildHouse() method. Is it worth asking that the use of exceptions would make the code cleaner? On the other hand, such cases usually present a situation where the user is required to code around what may be a poor design.

This topic and discussion may be nothing new, but I think it should help give thought to reasoning about the rule stated earlier regarding using exceptions for only exceptional conditions. Here were not talking avoiding programmer errors, such as trying to access a non-existent array element, but using exceptions to simplify a process.

While I'm not trying to suggest generally that using exceptions to control flow makes for better programs, I do think it is worthwhlie to consider such rules and understand why they may exist in the first place.

Saturday, August 6, 2011

First Steps with Fantom

I'm now finally getting around to taking my first steps with Fantom, even though I thought I would months ago. Where else would I start then "Hello World", and while I'm here, I'll toss in a comparison to the Java and Groovy versions for good measure:

Below is your classic Java "Hello World" program:

    public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}

Here is a Fantom version of the same program.

    class HelloWorld {
static Void main(Str[] args) {
echo("Hello World!")
}
}

There are a few differences worth noting:

  • The public keyword is not required.
  • The void keyword maps to a Void type.
  • The equivalent to String in Java is Str in Fantom.
  • The semicolon ending the singular statement in the Java version is not present in the Fantom version, in fact, including it would cause an error.

Also, the argument to the main method in the Java version is not required in the Fantom version:

 class HelloWorld { static Void main() { echo("Hello World!") } } 

Since I spend most of time with Groovy, I thought I'd consider the Groovy version. Like the Fantom version, the public keyword is not required, but the declared argument to the main method is, although we don't have to declare a type:

    class HelloWorld {
static void main(args) {
println "Hello World"
}
}

Additionally, the parentheses are optional and unlike with the Fantom version, an ending semicolon is allowed.

Now back to Fantom and getting the greeting printed out on the screen. The Fantom class can be placed in a file and run using the fan command:

  $ fan HelloWorld.fan
Hello World!

With Groovy, the println call can simply be placed in a file and executed as a script using the groovy command:

  $ cat hello.groovy
println "Hello World!"

$ groovy hello.groovy
Hello World!

Knowing this, I thought I'd try doing something similar in Fantom:

  $ cat hello.fan
echo("Hello World!")

$ fan echo.fan
/home/prystasj/workspace/Fantom/echo.fan(2,1): Expected 'class', not 'echo'
ERROR: cannot compile script

Unfortunately, we don't get the same results, but Fantom does have an interactive shell we can use, fansh:

  $ fansh
Fantom Shell v1.0.59 ('?' for help)
fansh> echo("Hello World!")
Hello World!
fansh> exit

Next, let's have the Fantom class make use of the array representing the arguments passed into the main method. In Fantom, arrays are also zero-based and accessed in the same way we are all used to:

   class HelloWorld {
static Void main(Str[] args) {
echo("Hello and " + args[0])
}
}

Running the progam with a single argument will have the argument included in the output:

  $ fan HelloWorld.fan goodbye
Hello and goodbye

Saturday, July 23, 2011

Groovy: Reducing Duplication with Closures

I've been using Groovy as my primary programming language for a few years now. One of the features that is commonly discussed and I've read about a lot are closures. While I've appreciated what I've read, I've had a difficult time recognizing good places to use them. Like I lot of things, if you "dont use it, you lose it".

One situation where I have been able to find uses for closures recently was using them instead of methods to reduce duplication that I can hopefully demonstrate using the following example scenario. We have a TextAnalyzer class whose sole responsibility is to analyze a string and report the words separated by commas and semicolons and the counts for said delimiting characters.

The TextAnalyzer.analyze() method below travels through a given string, aggregating words and counting commas and semicolons and returns an instance of TextAnalysis that contains the results.

For example, given the string:

    groovy,is,a,language;enjoyable

The result is:

    TextAnalysis(words:[groovy, is, a, language, enjoyable], commas:3, semicolons:1)

Here's the first version of the code. Of note here to me is the duplication that exists when either a comma or semicolon is found. In both clauses, the current word is pushed onto the words list and is reset in preparation for the next word.

    def text = "groovy,is,a,language;enjoyable"

new TextAnalyzer().analyze(text)

@groovy.transform.ToString(includeNames=true)
class TextAnalysis {
List words
int commas
int semicolons
}

class TextAnalyzer {

def analyze(text) {
def words = []
def word = ''
int commas = 0
int semicolons = 0

text.each { c ->
if (c == ',') {
commas++
words << word
word = ''
}
else if (c == ';') {
semicolons++
words << word
word = ''
}
else {
word += c
}
}

if (word) words << word

new TextAnalysis(words:words, commas:commas, semicolons:semicolons)
}
}

One option to remove the duplication is to add another method that would handle the push and reset of the current word, named add below:

    class TextAnalyzer {

private add(words, word) {
words << word
''
}

def analyze(text) {
def words = []
def word = ''
int commas = 0
int semicolons = 0

text.each { c ->
if (c == ',') {
commas++
word = add(words, word)
}
else if (c == ';') {
semicolons++
word = add(words, word)
}
else {
word += c
}
}

if (word) words << word

new TextAnalysis(words:words, commas:commas, semicolons:semicolons)
}

}

This works and produces the same result, however a couple of things bother me about it. First, the method is doing two things, it's adding the current word to the list, and return a value to reset the word. The user is required to know that it needs to assign the return value to the current word.

We could also used a boolean to indicate a word was complete that could of been evaluated at the end of each character evaluation, but that would add a bit more complexity to the analyze method through additional branching.

Another approach that sits better with me is to use a closure that's internal to the analyze method. Let's call it completeWord:

class TextAnalyzer {

def analyze(text) {
def words = []
def word = ''
int commas = 0
int semicolons = 0

def completeWord = { ->
words << word
word = ''
}

text.each { c ->
if (c == ',') {
commas++
completeWord()
}
else if (c == ';') {
semicolons++
completeWord()
}
else {
word += c
}
}

if (word) words << word

new TextAnalysis(words:words, commas:commas, semicolons:semicolons)
}

}

There are a few reasons I like this better besides the reduced duplication. Since the closure is defined within the method, it has access to the variables holding the current word and the list of words, so there's no need to pass the variables around. Also, since there are no other uses for either the previous method or the new closure, the code reads better having the logic to complete a word inside the method itself.

Of course, a really concise version of the analyze method probably would not iterate over the characters in the string at all (I was thinking I could of simply started with this version, but found the iteration helped illustrate things a bit more):

    class TextAnalyzer {
def analyze(text) {
new TextAnalysis(
words: text.split(',|;'),
commas: text.count(','),
semicolons: text.count(';')
)
}
}

The above though still has some duplication in the call to String.count(). We remove it using a closure that counts:

    class TextAnalyzer {
def analyze(text) {

def count = { c -> text.count(c) }

new TextAnalysis(
words: text.split(',|;'),
commas: count(','),
semicolons: count(';')
)
}
}

While we have not seen any huge wins here, in a more complex scenario, defining closures within methods could help make our code more readable and easier to maintain, which is always a win.

Tuesday, July 5, 2011

Spock: Varying Results from a Mocked Method

In the Groovy world, I'm a big fan of the Spock specification framework and have written about it before. One little challenge I ran into was to setup an interaction for a mock to return a different result depending on how many times its been called. To illustrate what I'm talking about, I'll set things up with the following little scenario.

Let's say we have a class, RecordProcessor whose job is to read records from a source until there are no more records to be read. A collaborator of the class, RecordReader, is responsible for the actual record reading, and is the class whose behavior we want to mock.

The method to be called on the RecordReader takes as a parameter, the number of records to read and reports whether or not there are more records left in the source to be read. For simplicities sake, let's assume the responsibility of the RecordProcessor is to simply invoke the RecordReader until it reports that there are no more records to read.

class RecordProcessor {

RecordReader recordReader
int threshold

def process() {
boolean isProcessingComplete = true
boolean recordsRemaining = true

while(recordsRemaining) {
recordsRemaining = recordReader.readRecords(threshold)
}

// would do more processing evaluation here...
processingComplete
}
}

We want our unit test to determine whether or not the class under test can detect when there are no more records to read and report that processing was completed. Here is the base of the Spock specification where the mocking setup is left to a method:

class RecordProcessorSpec extends Specification {

def threshold = 5
RecordProcessor recordProcessor = new RecordProcessor(threshold: threshold)

def "can process all the records accessible by a record reader"() {
given:
recordProcessorHasMockRecordReader()
when:
isProcessingComplete = recordProcessor.process()
then:
isProcessingComplete
}
}

The wiki page describing mocking and interactions can be found My first pass at setting up the mock looked like the below, where the first two calls to readRecords method would return true and the third would return false (for more on how mocking is done with Spock, see Interactions).

    def recordProcessorHasMockRecordReader() {
def mock = Mock(RecordReader)
2 * mock.readRecods(threshold) >> true
1 * mock.readRecods(threshold) >> false
recordProcessor.recordReader = mock
}

This didn't do the trick however as 3 invocations were detected for the first definition of how the method should behave:

  Too many invocations for:

2 * mock.readFrom(threshold) >> true (3 invocations)

I found one answer in using a closure to define the return value of the method invocation that had a bound variable to tracking the number of reads that were asked for:

    def recordProcessorHasMockRecordReader() {
def mock = Mock(RecordReader)
def readsAttempted = 0
3 * mock.readRecods(threshold) >> {
readsAttempted++
readsAttepted < 3 ? true : false
}
recordProcessor.recordReader = mock
}

With each invocation of the readRecords method by the RecordProcessor, the readsAttempted variable defined outside of the closure is incremented. With the first two calls, the RecordProcessor is told there are more records to process, and with the third call, it is told that all the records have been read.

Are there any other approaches anyone has found to approach a similar problem? Thanks.

Thursday, June 16, 2011

Experimenting with a Groovy Template Engine and PermGen

I had a Groovy application that was using a SimpleTemplateEngine was running out of PermGen space after running for a long period of time. The app was using version 1.7.10 and was running in a Tomcat 6 container.

Load tests consistently showed a linear increase in the PermGen consumption (monitored by JConsole). Originally, the template engine was used to create the template from the template text with every request. Also, the template was injected as a resource to the class using the engine.

After switching the class to create and cache the created template, we were still experiencing an OutOfMemoryError during the load test. Only after removing the use of the engine in its entirety, where we able to observe the PermGen leveling off.

A run of jmap -permstat PID against the application process showed a large number of entries of the form of:

  0x00000000f96bf800      24      233928  0x00000000f7f19558      dead    groovy/lang/GroovyClassLoader$InnerLoader@0x00000000fd784720

To investigate things, I thought I would try to see if I can reproduce the behavior using only a script run by Maven. As I go, I'll record what I see below. To start, I'll use Groovy 1.8.0.

The script will loop and complete a template with every iteration. The first version of the script will use a singe instance of SimpleTemplateEngine, but will call the createTemplate method with every iteration:

  def runs = 5
def templateText = 'Run number: ${runNumber}'
def engine = new groovy.text.SimpleTemplateEngine()

runs.times { i ->
def binding = [runNumber:"$i"]
engine.createTemplate(templateText).make(binding)
}

We'll start the script with verbose class loading on so we see what classes are loaded into PermGen during execution:

  $ export MAVEN_OPTS="-verbose:class"
$ mvn -o exec:java -Dexec.mainClass=TemplateEngine | tee /tmp/out
$ grep SimpleTemplateScript /tmp/out
[Loaded SimpleTemplateScript1 from file:/groovy/shell]
[Loaded SimpleTemplateScript2 from file:/groovy/shell]
[Loaded SimpleTemplateScript3 from file:/groovy/shell]
[Loaded SimpleTemplateScript4 from file:/groovy/shell]
[Loaded SimpleTemplateScript5 from file:/groovy/shell]

We might suspect that behavior since not only are reading the template everytime through the loop. A new version of the script below again uses the same SimpleTemplateEngine instance and only creates the template once:

  def runs = 5
def engine = new groovy.text.SimpleTemplateEngine()
def createdTemplate = engine.createTemplate(templateText)

runs.times { i ->
def binding = [runNumber:"$i"]
createdTemplate.make(binding)
}

With this version, we only see one class load:

  $ grep SimpleTemplateScript /tmp/out
[Loaded SimpleTemplateScript1 from file:/groovy/shell]

This is encouraging, but I want to make sure PermGen truly doesn't increase linerally over time. To do so, I'll add a sleep at the beginning of the script so I can attach JConsole to the Maven process and set the number of runs to a really high number:

  sleep(30000)
println "Starting..."
def runs = 50000

The PermGen graph is pretty jagged in the case where the createTemplate method is called each time through the loop. However, it appears that space was recovered as well so we do not end up running out of space:

To test the version where we only create the template once, I'm going to up the number of runs to 5,000,000 as execution is much faster without the repeated calls to the createTemplate method. The PermGen graph rises quickly but levels off:

So far, based on the verbose class loading and graph results, it looks like things are a definite improvement over what I was seeing in the original applcation. Just to be sure, I'm going to same experiment creating the template only once with version 1.7.0. as well.

With the single instance approach, the PermGen increased at a very slow rate. Using the approach where we call the createTemplate method with each iteration, the graph is again jagged:

At the end of this little experiment, I don't see any significant differences between Groovy 1.7 and 1.8. My work application was running in a Tomcat container which may also factor into things, along with a slightly different JVM version. Outside of the container, while the PermGen does rise with every load of a SimpleTemplateScript class, the memory is recovered.

I'll likely have to do some more experimentation to understand the behavior I was seeing in the original applcation.