Code for Concinnity

(This post started out as an elaborate explanation to someone who just couldn’t wrap his head around C++’s boost::tuple. The title is probably a misnomer. It sould be renamed “boost::tuples considered harmful outside of quick throw-away internal uses and TMP where they were actually intended to be used,” )

The examples here use C++, which has a very broken static type system. Some of these problems are only the ill effects of that. Some of these are inherent to tuples.

In particular, if you’re a budding C++ programmer who finally wants to try this new-agey feature from boost called tuples, this is a tutorial to tell you why you “don’t” want to go down that road.

Sin #1: Tuples makes you anti-social

Let’s look at the following piece of code:

By looking at the function declaration, how would you use divide?

How do you know which one is the correct usage? It turns out there is no way to know unless you look at the source code.

Forcing people to have to read your source code before they can use it is plain wrong.

Now it’s probably OK for dynamic languages (they tend to come from open source folks), but it will doom all C++ hardcore machos because knowing about breaks the OOP creed — encapsulation.

Some people think “parameter names suffer the same problem, you just need to name your method appropriately.” Here you go:

I don’t think I need to say more. No need to thanks for the laugh

Sin #2: Tuples leads to fragile code

Another example:

Fair enough, the type system actually helped us deduce the sensible usage:

So far so good. Fast-forward 6 months, it turns out our method wants to also include color information in the cube:

All of a sudden, original code breaks. Since there doesn’t exist function overloading for return types. Using tuple as your return type is a fast way to seal off your function for future extensions.

Sin #3: Tuples obfuscates your code

This demonstrates the serious problem of Sin #1 — every user of tuples need to go look up the source code

It also depicts another problem with tuples — PickUpTreasure()‘s writer must spell out the full definition of the tuples even though he only uses a handful of the values.

Sin #4: Tuples break type-safety

This function can be easily abused, and it compiles without problem:

What a pity.

So am I forbidden to return multiple values?

No. It’s called plain old struct

Old code can safely use the new struct as-is, without any modifications. Old code can even pass updated objects verbatim to new code that can enhance it. ’nuff said.

FAQs

1. Your second example sucks. I can say “using int as your return type is a fast way to seal off your function for future extensions”

True. Primitive types are usually expected to represent a very fine-grained entity that shouldn’t change. Of course it’s kind of an assumption. The problem with tuple is, tuple<int, int> is actually more like an object. tuple<int, int, char, char, std::string> even more so. The more types you pack together in a tuple, the more fragile that tuple is.

Think about it this way, if a function that originally returns int suddenly is changed to return std::string, the whole function probably needs to be rewritten anyway and the return type is the less of our concern (the more important concern is behavior, obviously). However, if your return type is tuple<int, std::string, double>, it is very likely that your function does more than one thing and you may well need to expand your return type to tuple<int, std::string, double, void *> some time later so you can expose more of your stuff that you originally thought could be encapsulated (this is a whole different topic).

Of course, no one can be absolutely sure he won’t want to return more things when he writes a function that returns more than one value. Think how struct handles it elegantly.

2. Defining a new type every time I want to stilt together a bunch of variables suck!

It does, but that’s a fact of life, embrace it. Understand that what you think is “a bunch of variables” may evolve into a full blown object sooner than you may think.

In a few convenient places, though, you can use tuple internally if you don’t expose tuples to the outside world (so other people don’t get confused). But how many non-trivial projects are internal? Even if your project is from the same company, it’s just good practice to write your part like an API so other people (including yourself 2 years later) can use it conveniently.

With those in mind, we can come to the conclusion that useful scenarios for tuples are really limited.

3. Your third example is stupid. Nobody uses tuples in parameter list. Functions have a natural parameter list that supports parameter naming

Right, let’s change it:

Seems better, let’s see how our caller adapts

Yikes!

Just for your comparison, here’s a well-formed and well-typed version using plain old OOP:

Who said programming languages must be cryptic!?

4. Your last remark in the third example shows your noobness. The author doesn’t have to spell out the definition of the tuple. He could have used a simple typedef

Right, but that kind of defeats the purpose of tuples IMO. The fact that I want to use a tuple is because it’s quick and dirty. If I go through the trouble to type:

Maybe I should just type a few more characters and benefit from named values:

Oops, it turned out to be less characters, ironically

5. How about out params? (Not really related to tuples)

It’s sometimes needed but should be avoided as much as possible:

In general, it’s better to return a struct by value given your struct holds a small number of primitive types (such as Point, Matrix, Rectangle, etc.). Because there is no performance penalty for returning a simple struct by value (see explanation below), but the added benefit is that the intent becomes crystal clear. The pass-by-value syntax is how programming languages should work, as God intended. I no longer need to worry about object life-times and a whole bunch of unimportant stuffs.

(For low-level machos, it’s notable that it’s faster for the CPU to juggle around primitive types in registers* than accessing them from memory. (But that’s another different beast topic.))

If you need to return a pointer, use their modern variants instead:

If you think about it, what’s an auto_ptr? It’s a struct! (class actually, synonymous in C++)

* I made that remark without really giving a deep consideration. I did a very crude test using a 2-double Point struct and made that conclusion. Obviously it’s very compiler specific. Most of the time, you’d find that the pass-by-value version is faster when you have 2 to 4 members in the struct, and your compiler is using some sort of fastcall or x64 calling convention. Having said that, it’s probably safer to stick back to good ol’ pass-by-const-reference most of the time anyway. For return values, we have RVO so it’s usually OK to return whole objects.

Today I checked out Arch Linux. It’s just that cool. It’s a minimalistic distro that focuses on, well, minimalism, simplicity and elegance.

What’s more of a pleasant surprise is that I find the Arch Linux Wiki to be probably the most comprehensive and high quality resources of Linux in general available on the net. Among those gems, I’ve found the way to change the font at the console. I’ve been using nix environments for a couple of years and this is the question that has always bugged me but nobody seemed to have talked about. There you go, several years of research

Setting up Arch Linux was a pleasant learning experience from itself. The package manager pacman offers the same level of convenience as the famous apt, if not more. The nice thing about it is that Arch’s packages seem to be much more recent than those ancient rugs on Debian and Ubuntu.

At the same time, Arch doesn’t bog you down with lots of unnecessary stuffs. Right out of the box, Arch almost doesn’t have any packages, and you have to edit a couple of config files just to be able to download things from the repos. But it was a pleasant learning experience, largely attributable to the excellent wiki.

If you want to improve your nix-fu or just want plain, beautiful distro to play with, give Arch a try!

In my last article about unit testing, I mentioned one way to do ad-hoc multiple joins in CakePHP rather succinctly. Here’s a recap:

This is, of course, rather unintuitive. A hasOne relationship when in fact I’m trying to look for someone hasAndBelongsToMany? I thought more about it.

There is a Bakery article that talked about doing ad-hoc joins. It looks more technically correct but just too freaking much verbose for my liking:

Actually, a simple refactoring can make it (almost) syntactically sweet and technically more correct:

Today I’ve finally formalized a streamlined procedure to do unit testing properly in CakePHP — without all the pain. Needless to say, The Cookbook’s chapter on this issue cover the basic grounds but is inconsistent and lack a real life feeling to it.

The Cookbook’s coverage is really basic and doesn’t hold up to more real life complicated cases. Cake seems to be particularly picky about its automagical (too clever for me to figure out for a long time) configurations and bark errors at me very often. That led to reluctance to write tests and sometimes giving it up all together :p

The steps I’ve written here should lay down a very solid framework to make you bullet proof for all your future testing needs.

(Of course, this might be coming a bit late since most people would be better off looking at Cake’s successor Lithium, anyway here we goes.)

Can’t gather up much time to make a polished article but I believe this point-form brain dump is much more effective than most documentation out there.

Testing models

First, some notes

• Testing models is the most important thing. Of course, a proper MVC application should have fat models and thin controllers.

• For the most part, you really should use fixtures even if you do not use fixtures to load data. If you just use the database live, chances are Cake might mess up your data and errors might pop up, just go ahead and use fixtures. Yes, you don’t need to load data with your fixtures if you don’t want, but you need to turn this feature on. Yes, this was the thing that confused me a lot.

• CakePHP uses SimpleTest, you would think that you’d put your setup and teardown code in setUp() and tearDown() just like everybody else? Wrong. Cake has already invaded those spaces. You’ll need to use startTest() and endTest(). This was documented in the Cookbook but this took me quite some time to figure out since I took it for granted and didn’t RTFM.

• I may cover controller testing later but IMO controller testing in Cake is mostly broken and is quite straight forward to figure out.

Testing models — the tutorial

First we’ll set up the database, install SimpleTest etc. If you don’t know how to do this step you should read the Real Manual first.

Set up our testing application database in (My)SQL.

Bake our stuffs. Bake has come a long way since the earlier versions and the bake in Cake 1.3 is genuinely useful:

Now go create some test data:

Now open /app/models/post.php and /app/models/tag.php. Both look OK! And Cake has gone ahead and created the test cases for us at /app/tests/cases/model. Let’s try to run it

This is how broken it is! Now let’s fix it. The thing is that we haven’t baked the fixture for the join table class PostsTag. Of course, we don’t want to have to create controller, models, views just for a simple join class. Luckily we can amend it by creating all missing fixtures:

This will create all the missing fixtures. The -records -count 999 part tells Cake to pull real data from our database as fixture. The -count part is needed because it defaults to 10. Might as well enter some very large number but YMMV. This will also update our existing fixtures for Post and Tag so that the new fixture data we’ve added to the database will be reflected in the fixtures. Let’s try to run the tests again:

Finally, we’ve got the testing architecture down. To honor TDD, let’s create (edit) our test file before we do some development. Now go to /app/tests/cases/models/post.test.php, you’ll see this line:

This is unfortunate, because it means every time you add a new association to your model, you’ll have to manually edit this $fixtures array. Too bad there isn’t an automated way to do this. (Running bake test will overwrite your whole file. You’ve been warned!)

Anyway, let’s just write some tests for kicks in /app/tests/cases/model/post.test.php:

Run it, all is good:

To honor TDD, we’ll write our test first before we do any implementation. Let’s add our test function. We’re going to write a model function that will find all posts for a given tag:

Run the test and watch it fail:

Do our implementation in /app/models/post.php

The above trick was used to force CakePHP to do left joins for us. There is an article that talks about this technique on the nuts and bolts of cakephp blog.

Well, let’s add one more test. We want to make a function to get us the content of a post:

Run it, watch it fail. And then we add our implementation:

Great, now run it and expect it to pass….

Wtf!? It failed? Yeah, we forgot to update our fixtures. That’s it. Every time we update our database, we need to update the fixture. Fortunately, this is one area from Cake that is really painless:

The fixture updating part was a little redundant, but it’s better than manually updating the fixture from SQL and also from *_fixture.php. I suggest you can store all your test fixtures data into an SQL file and make some bash script or ruby script to deconstruct the database and load the test SQL file for each test run. You can play around with different connection settings if you don’t want to sabotage your main table for every test run. You can package this loading of SQL file and the fixture baking into one script file so that it can be done in one click. (left as an exercise to reader)

That’s it! In retrospect, it isn’t rocket science, it’s just that I haven’t found any good piece of comprehensive tutorial that hand holds me from start to finish. I’ve been putting off a lot of unit test writing because I’ve always had Cake barking errors at me left and right. Now there’s no excuse