Cleverly Titled Blog

Wednesday, January 6, 2010

Dynamic Method Interceptors in Scala

In my previous post I showed a rough simulation of Clojure's multimethods implemented in Scala. What if we wanted to extend that to allow dynamic interceptors on these methods?

Here's example usage showing how they stack on each other:

val numToString = DynDispatch.defMulti { i: Int =>
i match {
case 1 => "one"
case 2 => "two"
case 3 => "three"
case _ => "bignumber"
}
}

numToString(2) // "two"

// add logging?
numToString.onMethod { (i, s) =>
println("called numToString(" + i + ") and returned: " + s)
}

numToString(3) // called numToString(3) and returned: three

numToString.beforeMethod { _-1 } // evil... subtract one from input

numToString(3) // called numToString(3) and returned: two

numToString.afterMethod { _ toUpperCase }

numToString(2) // called numToString(2) and returned: ONE

numToString.afterMethod { _.substring(1) }

numToString(2) // called numToString(2) and returned: NE

numToString.aroundMethod { f =>
{ i: Int => f(i+1).reverse }
}

numToString(2) // called numToString(2) and returned: OW

numToString.aroundMethod { f =>
{ i: Int => "hello" }
}

numToString(2) // called numToString(2) and returned: hello


Our dispatcher definition looks like this:

object DynDispatch {
class DynMethod[A,R] {
import scala.collection.mutable.ListBuffer
private[this] val methods = ListBuffer[PartialFunction[A,R]]()
private[this] val around = ListBuffer[(A=>R) => (A=>R)]()
private[this] val on = ListBuffer[(A,R)=> Unit]()

def defMethod(m: PartialFunction[A,R]) = methods += m
def beforeMethod(b: A => A) = around += { f => { x => f(b(x)) } }
def afterMethod(a: R => R) = around += { f => { x => a(f(x)) } }
def aroundMethod(a: (A=>R) => (A=>R)) = around += a
def onMethod(o: (A,R) => Unit) = on += o

def apply(args: A): R = {
def applyChain[X,Y] = { ( x: X, f: X => Y) => f(x) }
def innerApply: A => R = { a: A =>
methods.reverse.find(_.isDefinedAt(a)) match {
case Some(f) => f(a)
case None => throw new Exception("Method not defined for: " + a)
}
}
val result = (around.foldLeft(innerApply)(applyChain))(args)
on foreach { _(args: A, result: R) }
result
}
}

def defMulti[A,R] = new DynMethod[A,R]
def defMulti[A,R](f: A => R) = {
val dm = new DynMethod[A,R]
dm.defMethod { case a => f(a) }
dm
}
}


And, here is an example class hierarchy showing some usage:

trait Comedian {
def perform(props: Props) = "Generic performance"
}

// comedic props
trait Props
case class NoProps extends Props
case class SledgeHammer extends Props
case class MultipleProps extends Props

trait DynamicComedian extends Comedian {
// make perform dynamic
val perform = DynDispatch.defMulti(super.perform _)
override def perform(props: Props) = perform.apply(props)
}

class Gallagher extends DynamicComedian {
perform.defMethod { case p: MultipleProps =>
"Lots of stuff"
}
perform.defMethod { case p: SledgeHammer =>
"Somebody is getting messy"
}
}

class ChrisRock extends DynamicComedian {
perform.defMethod { case p: Props =>
"Tell black jokes"
}
}

class GeorgeLopez extends ChrisRock {
perform.afterMethod { result =>
result.replaceAll("black", "latino")
}
}

class GeorgeCarlin extends DynamicComedian {
perform.defMethod { case p: Props =>
"I don't need any fuckin' props... shit!"
}
perform.defMethod { case p: NoProps =>
"Let me tell you about swear words"
}
}

trait LoggingComedian {
self: DynamicComedian =>
perform.onMethod { (props, result) =>
println("result: " + result)
}
}

trait UnpaidComedian {
self: DynamicComedian =>
perform.aroundMethod { perf =>
(props) => "Whatever, I'm not performing"
}
}

object App extends Application {

val gl = new GeorgeLopez with LoggingComedian
gl.perform(NoProps()) // result: Tell latino jokes

val gc = new GeorgeCarlin with LoggingComedian
gc.perform(NoProps()) // result: Let me tell you about swear words

val g = new Gallagher with LoggingComedian
g.perform(SledgeHammer()) // result: Somebody is getting messy

val gu = new Gallagher with LoggingComedian with UnpaidComedian
gu.perform(SledgeHammer()) // result: Whatever, I'm not performing

}


Now, if you haven't fallen asleep by now, you are probably wondering why we would go through this trouble? The Comedian class hierarchy with mixin traits could be more clearly and performantly defined statically using standard method overrides.

For example, the LoggingComedian trait could be defined like:

trait Comedian {
def perform(props: Props) = "Generic performance"
}

// comedic props
trait Props
case class NoProps extends Props
case class SledgeHammer extends Props
case class MultipleProps extends Props


class Gallagher extends Comedian {
def perform(p: MultipleProps) = {
"Lots of stuff"
}
def perform(p: SledgeHammer) = {
"Somebody is getting messy"
}
}

class ChrisRock extends Comedian {
override def perform(p: Props) = {
"Tell black jokes"
}
}

class GeorgeLopez extends ChrisRock {
override def perform(p: Props) = {
super.perform(p).replaceAll("black", "latino")
}
}

class GeorgeCarlin extends Comedian {
override def perform(props: Props) = {
props match {
case p: NoProps => "Let me tell you about swear words"
case _ => "I don't need any fuckin' props... shit!"
}
}
}

trait LoggingComedian extends Comedian {
override def perform(props: Props) = {
val result = super.perform(props)
println("result: " + result)
result
}
}

trait UnpaidComedian extends Comedian {
override def perform(props: Props) = {
"Whatever, I'm not performing"
}
}


So, unless you need the runtime argument specialization that defMulti provides, there is no need for the interceptors, right?

Let's run it:

object App2 extends Application {

val gl = new GeorgeLopez with LoggingComedian
gl.perform(NoProps()) // result: Tell latino jokes

val gc = new GeorgeCarlin with LoggingComedian
gc.perform(NoProps()) // result: Let me tell you about swear words

val g = new Gallagher with LoggingComedian
g.perform(SledgeHammer()) // no output!!

val gu = new Gallagher with LoggingComedian with UnpaidComedian
gu.perform(SledgeHammer()) // no output!!

}


What happened? Why is Gallagher not logging? Well, if you want to override a method in a trait, you need to override each combination of the arguments (here, SledgeHammer in addition to the generic Props).

Another useful property of the dynamic interceptors for this usage pattern is that you can use a class in the self type of the mixin, and not just a trait (what if Comedian was concrete?).

But, the most dramatic effect of these dynamic interceptors is that you can now get non-lexical, dynamic scoping. You can attach interceptors to individual instances of Comedian and send them down the call stack.


val georgeCarlin = comedianService.get("George Carlin")

georgeCarlin.perform.aroundMethod { f =>
(props) => {
myCallBack(props)
"Hear the one about the observer pattern?\n" + f(props)
}
}

myOtherService(georgeCarlin)


Any other uses?

Sunday, January 3, 2010

Dynamic Dispatch in Scala

Clojure has runtime polymorphism that goes beyond the single, receiver-based dispatch that you find in Java or Scala. You can dispatch based not only on the type of all objects involved (multiple dispatch), but also on the result of an arbitrary function (predicate dispatch).

Why should I care? Let's explore this in Scala using the Bunny/Lion example as shown on Clojure site.


trait Animal {
def encounter(a: Animal) = "Generic animal encounter"
}

class Bunny extends Animal {
override def encounter(a: Animal) = "Generic Bunny encounter"
def encounter(b: Bunny) = "Mate"
def encounter(l: Lion) = "Run away"
}

class Lion extends Animal {
override def encounter(a: Animal) = "Generic Lion encounter"
def encounter(b: Bunny) = "Eat"
def encounter(l: Lion) = "Fight"
}


This does what we want in a straight-forward example:

val bunny = new Bunny
val lion = new Lion
bunny encounter lion // Run away
bunny encounter bunny // Mate
lion encounter lion // Fight
lion encounter bunny // Eat


But, what happens if we are dealing with a List[Animal]? Or, we have some convenience function like this:

def printEncounter(a1: Animal, a2: Animal) = {
def s(a: Animal) = a.getClass.toString.split("\\.").last
println(s(a1) + " vs " + s(a2) + ": " + (a1 encounter a2))
}
val bunny = new Bunny
val lion = new Lion

printEncounter(bunny, lion)
printEncounter(bunny, bunny)
printEncounter(lion, lion)
printEncounter(lion, bunny)

/* Output:
* Bunny vs Lion: Generic Bunny encounter
* Bunny vs Bunny: Generic Bunny encounter
* Lion vs Lion: Generic Lion encounter
* Lion vs Bunny: Generic Lion encounter
*/


Oh, my! We seem to have dynamically determined which method definition to use based on the runtime type of the receiver object, but not on any of the objects in the argument list. This is the standard functionality you get with Java or Scala.

How would we fix this in Scala? A first pass might look like this:

trait Animal {
def encounter(a: Animal) = "Generic animal encounter"
}

class Bunny extends Animal {
override def encounter(a: Animal) = a match {
case b: Bunny => "Mate"
case l: Lion => "Run away"
case _ => "Generic Bunny encounter"
}
}

class Lion extends Animal {
override def encounter(a: Animal) = a match {
case b: Bunny => "Eat"
case l: Lion => "Fight"
case _ => "Generic Lion encounter"
}
}


Of course, like Clojure's multimethods, pattern matching in Scala is not limited to just type information, but can also look at dynamic runtime information. You could easily imagine a lazy rabbit that only ran from lions that had been identified as hungry at the time:

class Bunny extends Animal {
override def encounter(a: Animal) = a match {
case b: Bunny => "Mate"
case l: Lion if (l.isHungry) => "Run away"
case l: Lion => "Ignore"
case _ => "Generic Bunny encounter"
}
}


So, how is this different from the Clojure approach? Rich Hickey commented on this, which I'll quote here:
Multimethods differ from pattern matching in a number of ways. Two that matter (to me) are:

Pattern matching is usually ‘closed’, in the sense that all possibilities must be enumerated in a single scope.

Pattern matches are usually declaration order dependent.

Multimethods, OTOH, are an open set. You can define a new method any time, anywhere – they need not be lexically co-located. Multimethod operation is independent of definition order. They are very dynamic, and thus a good fit for Clojure.

There are other differences, of course, e.g. pattern matching usually has sugar for structural and type matches, and often exhaustiveness checking. I’m still waiting for someone to contribute a pattern-matching macro for Clojure, as I don’t think one makes the other redundant.


What could we do in Scala to address some of the deficiencies that Rich is pointing out? A dispatch mechanism could be defined like this:

object DynDispatch {
class DynMethod[A,R] {
val methods = scala.collection.mutable.ListBuffer[PartialFunction[A,R]]()
def defMethod(m: PartialFunction[A,R]) = {
methods += m
}
def apply(args: A): R = {
methods.reverse.find(_.isDefinedAt(args)) match {
case Some(f) => f(args)
case None => throw new Exception("huh?")
}
}
}
def defMulti[A,R] = new DynMethod[A,R]
}


Class and method definition would then look like this:

trait Animal {
val encounter = DynDispatch.defMulti[Animal, String]
encounter.defMethod { case a: Animal =>
"Generic Encounter"
}
}

class Bunny extends Animal {
encounter.defMethod { case a =>
"Generic Bunny Encounter"
}
encounter.defMethod { case b: Bunny =>
"Mate"
}
encounter.defMethod { case l: Lion =>
"Run away"
}
}

class Lion extends Animal {
encounter.defMethod { case a =>
"Generic Lion encounter"
}
encounter.defMethod { case b: Bunny =>
"Eat"
}
encounter.defMethod { case l: Lion =>
"Fight"
}
}


Calling syntax is the same as with the traditionally-defined methods, but the methods are dispatched dynamically. This seems to address the "closed" issue of needing to enumerate all the possibilities within a single scope. Heck, you can even add or redefine methods for individual instances of objects:

val lion = new Lion
val bunny = new Bunny
bunny.encounter.defMethod { case l: Lion if (!l.isHungry) =>
"Ignore"
}
bunny encounter lion // depends on if the lion is hungry


Note that the methods are still type-safe, as the type of the argument list is required to be declared in the DynDispatch.defMulti[A,R] method. For methods that have differing arities or disjoint types, you lose some type safety, but the syntax is still convenient:

class TigerWoods {
val tryst = DynDispatch.defMulti[AnyRef,Alimony]
tryst.defMethod { case m: Mistress =>
Alimony(1000000)
}
tryst.defMethod { case (m1: Mistress, m2: Mistress) =>
Alimony(5000000)
}
}

// ...

val t = new TigerWoods
t.tryst(Mistress("Diane"))
t.tryst(Mistress("Emily"), Mistress("Sara"))


One big disadvantage of this implementation is the runtime overhead of method definition and queuing with each object instantiation. I don't know to what extent this could be minimized with some magical combination of caching and laziness.

We are also still dependent on order of definition to resolve any ambiguities within the method definitions. This naive implementation takes the easiest path and matches from bottom to top within a scope, with scopes from instance -> subclass -> superclass. A more sophisticated approach would find the "most specific" combination of the receiver and argument list, with ambiguities resolved with runtime exceptions or some other approach (like order dependence).

I like the order dependence of pattern matching within Scala, where the different cases are all present within the same block. However, for this application, with methods defined in multiple places, I can see it as a source of confusion. But, I'm also not a big fan of discovering ambiguities at runtime.

What is your favorite way to dispatch?

Monday, November 9, 2009

OKCJUG Lightning Talks

This month, we will have lightning presentations... 5 minutes and 20 slides set on auto-timer. I'll do some TDD and ScalaCheck directly through powerpoint! Get it here.

Thursday, October 29, 2009

ScalaCheck is Neat-o!

ScalaCheck is a testing library for Scala (and Java!). It is a step beyond just writing tests, you actually assert properties of some code and it generates a number of tests dynamically to test it.

A recent example of using this came from this StackOverflow question. It required a largish number of test cases, so it seemed a perfect fit to try out ScalaCheck.

The code to test was:


package blevins.example

object BigIntEncoder {
val radix = 36

implicit def byteArrayToString(ba: Array[Byte]): String = {
new java.math.BigInteger(ba).toString(radix)
}

implicit def stringToByteArray(s: String): Array[Byte] = {
new java.math.BigInteger(s, radix).toByteArray
}

}


To test, you write something like this:


package blevins.example

import org.scalacheck._

object BigIntEncoderSpecification extends Properties("BigIntEncoder") {
import Prop._
import Gen._

def genArray( fill: Array[Byte] => Unit) = Gen.sized { size =>
val bytes: Array[Byte] = new Array[Byte](size)
fill(bytes)
bytes
} suchThat (_.size > 0)

def filledByteArray( i: int ) = genArray(bytes =>
for (i <- 0 to bytes.length - 1) { bytes(i) = i.asInstanceOf[Byte] }
)

val arbByteArray = genArray(bytes => scala.util.Random.nextBytes(bytes))

val zeroByteArray = filledByteArray( 0x00 )

val fullByteArray = filledByteArray( 0xff )

def checkEncodingRoundTrip = { (ba: Array[Byte]) =>
import BigIntEncoder._
ba deepEquals stringToByteArray(byteArrayToString(ba))
}

property("random") = forAll(arbByteArray)(checkEncodingRoundTrip)
property("zero") = forAll(zeroByteArray)(checkEncodingRoundTrip)
property("full") = forAll(fullByteArray)(checkEncodingRoundTrip)
}



This code will generate random, all-zero, and all-binary-ones (0xff) arrays and test their equality using the checkEncodingRoundTrip method, which exercises the code to be tested. It failed sometimes for the random array, and failed all the time for the other two types. I also noticed that the random array failed when the first byte of the arrays was either 0x00 or 0xff. I assumed that this was a side effect of BigInteger taking the two-complement of the byte array, so I padded it like so:


package blevins.example

object BigIntEncoder {
val radix = 36

implicit def byteArrayToString(ba: Array[Byte]): String = {
new java.math.BigInteger(addByte(ba)).toString(radix)
}

implicit def stringToByteArray(s: String): Array[Byte] = {
stripByte(new java.math.BigInteger(s, radix).toByteArray)
}

def addByte(ba: Array[Byte]): Array[Byte] = {
val h = new Array[Byte](1)
h(0) = 0x01
h ++ ba
}

def stripByte(ba: Array[Byte]): Array[Byte] = {
ba.slice(1,ba.size)
}

}


This produced the desired results (all passing), but a large amount of output. I wrote my own output-generator like this:


package blevins.example

object Test extends Application {
import org.scalacheck._
import org.scalacheck.Test._

val params = Params(5000, 10, 1, 100, new java.util.Random(), 1, 1)
val props = checkProperties(BigIntEncoderSpecification, params)
for ((name, result) <- props) {
println(name + ": " + result.status)
}

}



This also increased the number of tests-per-property from 100 to 5000.
My output was:

BigIntEncoder.random: Passed
BigIntEncoder.zero: Passed
BigIntEncoder.full: Passed


Yay! Now go watch TV.

Reflective Calls in Scala

Scala 2.8 contains two experimental features to reflectively invoke methods. Are these cool?


import scala.reflect.RichClass._

val hello = "hello"
val helloStartsWith = classOf[String].reflectiveCall(hello, "startsWith")
val b1: Boolean = helloStartsWith("hell")
val b2: String = helloStartsWith("heaven") // ClassCastException (Boolean->String)
val b3 = helloStartsWith("blah") // ClassCastException (Boolean->Nothing)


import scala.reflect.Invocation._

val team: AnyRef = "team"
val any = team o 'contains("I") // returns 'Any'
val b4: Boolean = team oo 'contains("I") // ok
val b5 = team oo 'contain("I") // ClassCastException (Boolean->Nothing)



The methods called using "o" return "Any". Both reflectiveCall(...) and the "oo" version return the inferred type. Note that this doesn't relieve you from knowing the expected result type, or further reflecting it and casting. This is shown in the runtime errors with b2, b3, and b5.

EDIT: This post was accurate for the nightly 2.8 release when it was written, but this code appears to have been removed from the latest 2.8 betas.

Thursday, August 13, 2009

BOM Differences

Sometimes it helps me think about my work if I write it out on virtual paper. So, be warned that this post will probably not be very entertaining or educational. But, I do promise that there is an obscure reference to the movie "Kung-Fu Panda" hidden within.


Here's an interesting project I'm working on. The goal of the project is to effectively visualize the differences between two Bills of Materials (BOMs) from our ERP system. For those unfamiliar with BOMs, they are just a hierarchical structure of the components that make up a product being manufactured. A real nerd might call it an acyclic, directed, weighted (weights are the quantities) graph. But, it is easier to just think of it as a tree.

Turns out that it is pretty useful to be able to easily see what the differences are between two different bills of materials, especially for people who like to scratch their heads and figure out how to make the product cheaper, or what price to sell it for, or assign costs to products, etc.

The first thought I hatched when thinking about how to implement this was to see how close my needs were to the Java Structure Comparison tool in Eclipse. I have put many hours into driving this particular IDE, and it seems similar to what I wanted.

For those unfamiliar with it, you can take a class that is similar to this:

package com.iecokc.cooking;

public class CakeRecipe {
public String flour;
public String eggs;
public String frosting;
public void beatEggs() {}
public void stir() {}
}

And another class like this:

package com.iecokc.baking;

public class CakeRecipe {
public String flour;
public String eggs;
public void beatEggs() {}
public void stirBriskly() {}
}

and you end up with a navigable tree that shows only the differences, like this:
Java Structure Compare

The problem with the comparison implemented in Eclipse is that it uses a strict definition of node identity in the trees that is compares. For example, if I had renamed the one of the classes from "CakeRecipe" to "BundtCakeRecipe", Eclipse would have refused to even consider that these might be similar in structure and therefore should be compared. Nope, different class name or method signature means that it is a completely different thing.

Instead, I needed to have my comparison consider the concept of something being "mostly equal", or "mequal" (trademark pending). If I can pin down this slippery concept of "mequals", I can then make a comparison structure that shows more than just adds and removes, but also edits of a particular node. It might look like the mock-up below (courtesy of Brent).
BOM Difference Mockup

In the tree above, two BOMs (say, "A" and "B") are compared. The green nodes with a "+" next to them represent nodes that were added (in "B" but not in "A") and the red nodes with a "-" represent nodes that were removed (in "A" but not in "B"). The blue nodes with the pencil represent nodes that are in both BOMs, but are different in some way (a.k.a. - mequal).

Now, there are many nodes that are exactly equals in both BOMs. It might sometimes be useful to show them, and it would look like the gray nodes below:
Full BOM structure comparison

So, how do I go about identifying the nodes that are mequal to each other between the two BOMs? Well, it is not just a function of the two nodes in consideration, but also a function of the structure that they contain, and the structure that they are contained in. For example, if there is a panel (however these are identified) in the top-level of each BOM, then these would probably be considered to be mequal. But, if there are two panels in BOM "A" and only one in BOM "B", then there is a choice to be made: which panel in "A" is more mequal to the one in "B"? Answering this question may need to consider the structure (child nodes) of the panels being analyzed.

Whew! This seems like it will be hard work. So, I'll search for libraries that already implement it. Since a BOM is a tree structure that could be represented in XML, maybe an XMLDiff library exists that I can leverage. Let me search... yup! There are about a thousand and one XML diff libraries, but I couldn't find a maintained one that worked on unsorted nodes and didn't rely on strict node identity.

So, I search the research publications. I particularly like some of the ideas from this paper. I'll charge blindly forward and try to implement it. The next few blog posts will be about the implementation (if successful).

Tuesday, July 28, 2009

Fuggin Programming



WARNING: STRONG LANGUAGE AND BAD CODE

Hey, Folks! Blago here.
I'm programmin now! What, you didn't know I was doin that? Well, fuck you. I don't have much know-how under my belt yet, but I'm learnin this Scala shit that all the kids seem to be playin with. It's fuckin great. I mean, where else can I make a method name of "?<!#%^&*" and get away with it? The syntax looks just like I talk.

So, what can I code? What I know about is governing, so let me distill this knowledge down to a mini-quick how-to-govern trait:


trait Governance {

type Favor
type Promise
type ShitIWant
type Lobbyist
type Bribe

def solicit(favor: Favor)(lobbyist: Lobbyist): Bribe
def pickBest(bribes: Seq[Bribe]): Bribe
def accept(bribe: Bribe): Promise
def collect(promise: Promise): ShitIWant

def govern(lobbyists: List[Lobbyist], power: Seq[Favor]) = {
for (favor <- power) yield
collect(accept(pickBest(lobbyists.map(solicit(favor)))))
}

}



I make it look easy, huh? Let's break it down now. The world of politics is made up of Lobbyists, Favors, Promises, and Bribes. Oh, and also shit-I-want. The whole point of all the other stuff is to get more shit-I-want.

So, let's look at the govern method. The inputs needed to govern are Lobbyists and Power. The Power gives you a steady stream of Favors that you can do for people, and you can keep that power as long as you *ahem* stay in office. Then, you got the Lobbyists. These fuckin pricks just want to get you to do favors for them for free. Don't be a dumbass, if you got somethin golden, make'em pay up the ass for it.

def govern(lobbyists: List[Lobbyist], power: Seq[Favor]) = { ... }


How can you get the best deal for your Favors? Well, you can't just give it to the first asshole that comes along. You gotta shop it around. Get out your little black book and make some calls. This is illustrated in the solicit method

def solicit(favor: Favor)(lobbyist: Lobbyist): Bribe


So you solicit your current Favor to every fuggin lobbyist you know, and try to get a Bribe from each of them. Then, you can compare them all to get the best one.

def pickBest(bribes: Seq[Bribe]): Bribe


The best Bribe you can then accept, getting a Promise to pay up. You then collect on that Promise to get the ShitIWant, which is usually in the form of small unmarked bills (but not /that/ small).

def accept(bribe: Bribe): Promise
def collect(promise: Promise): ShitIWant


Notice that I'm usin what they call "abstract types" in this trait. That means that a type like "ShitIWant" could really be anything (like money), and needs to be defined by the implementing class.

What? You thought I was gonna implement the class myself and do all the work for you? Why don't you fuck yourself in the ear. Then, when you're done with that, go fuck yourself in the other ear. Then, come back and ask nicely, cause I'm not your fuckin jump-to-it kid.

Oh, all right. Since I'm such a nice guy, here's what a class might look like that extends my Governance trait.


object MyGovernance extends Governance {

type Lobbyist = { def bribe(f: Favor): Bribe }
type Favor = String
case class Bribe(favor: Favor, amount: BigDecimal)
case class Promise(bribe: Bribe)
case class ShitIWant(amount: BigDecimal)

def solicit(favor: Favor)(lobbyist: Lobbyist) = {
lobbyist.bribe(favor)
}

def pickBest(bs: Seq[Bribe]) = {
bs.foldLeft(Bribe("Nothing",0))((a,b)=> if(a.amount >= b.amount) a else b)
}

def accept(bribe: Bribe) = {
Promise(bribe)
}

def collect(promise: Promise) = {
ShitIWant(promise.bribe.amount)
}

}



Notice that all those abstract types used to really be nothin more than names just floatin in space. But I had to tie them to something to implement the class. So, the "Favor" type is now just a type-alias for a String, so it could be something like "Pardon a rich man" or "Direct money to Project X". Other types, like Bribe, I defined directly.

So the jagoff implementing this class only needs to implement the component methods solicit, pickBest, accept, and collect. The basic structure of governing is already defined by me in the govern method, and it doesn't need any improvement. I heard some asshole talking about "idiomatic scala" and he said my code don't have it. Well, I told him that he must be an idiomatic because he didn't get any oxygen to his brain when he was in the womb and his mother was a whore.

But anyway, I can take constructive criticism. And, I started hearin about this shit called "composable functions". What's that? You just take some of these methods and plugem together to make new ones. You don't even need to define arguments and return types and shit like that, although the compiler will make sure you don't do anything stupid. Like, the place where I cherry-pick the best bribe and follow-through on it. In scala, I can define something like this:

def cherryPick = pickBest _ andThen accept andThen collect


Lookit that. Now I got a new method that combines all those other methods together, but I can treat it like a single thing. Also, I can plug in the pieces of this thing in other ways to into other methods and treat them like lego building blocks. I love legos. Then, my govern method becomes more compact.

def govern(lobbyists: List[Lobbyist], power: Seq[Favor]) = {
for (favor <- power) yield
cherryPick(lobbyists.map(solicit(favor)))
}


If you were payin attention, you might be thinking that I could've saved a lot of trouble in defining all of those methods to plug together if I just would've defined the combined function from the start to implement at once:

def cherryPick(bribes: Seq[Bribe]): ShitIWant


Then, you can implement it all at once and skip those pesky pickBest, accept, and collect methods:

def cherryPick(bribes: Seq[Bribe]): ShitIWant = {
val amt = bribes
.foldLeft(Bribe("Nothing",0))((a,b)=> if(a.amount >= b.amount) a else b)
.amount
ShitIWant(amt)
}


Whoah... slow down there, brother. I could have also just stubbed out the "govern" method and made you implement the whole fuckin thing. But, I'm tryin to supply a structure for you to base you implementation on. If you want to learn how to govern you better shuddup and pay attention. Not just the structure of the code I'm givin you is important, but also the semantics of the code. I took painstaking effort to name the types and variables so that you can understand the subtle meanings of all the players in this dance.

As a side note, the type names can (and should) be changed to reflect new meanings and realities. They are a communication tools just like code comments. But, also like comments, they can lie to you if you're lazy and let your code drift. For example, I recently found out that Lobbyists are not the only entity from which I can extract bribes. So, I should have refactored my code to include some super or genric type that includes Congressmen. So, if type/method/variable names are like comments and can lie to you. Maybe we should all just be using one-character variable names to at least limit the damage they can do. Then, the structure of the code pops out at you, unhindered by the story told by the names.

This guy obviously has mental problems:
After you have spent a certain amount of time in the compiler, you will
come to feel angry resentment at every comment you encounter, because it
might be trying to mislead you! I have modified my editor not to show me
any comments in scala sources so they cannot tempt me with their siren
songs of reasons and explanations. AH THE LIMITLESS SERENITY


Michael Feathers is all over this topic today on Tweeter. See if you can pick out the posts that matter from all of the other crap on there. I swear, people join Twatter because they think other people like the smell of their farts, then they stay because they start to like the fart-smell themselves. Fuggidaboutit.

The trade-off between names and structure appears to be constrained by ease-of-comprehension on one end and the need for reuse/composability on the other. Feathers considers that there are certain classes of code that are better understood in terms of their structure, effectively bridging the comprehension/composability divide.

Ha! He'll never get anything done if he keeps jackin around thinkin useless thoughts like that. Meanwhile, I just automated the entire process of executive governing. I'm ready for my next challenge to help the world... I think I'll make a web-framework in Java. That'll be fuckin Golden!