The Anatomy of an Iguana App

File Abstraction Library

One of the frustrating things about the first version of the channel manager was that we’d get it working on a Mac, and then it wouldn’t work on Windows. We’d fix it on Windows and find we’d broken the Mac side again.  We only barely managed to have it working for that first masters class, although we did get it done!

The pain comes from the fact that Mac OS X, together with Linux and the rest of computing world, represents directory separators using forward slash characters: ‘/’.  Windows, on the other hand, by convention uses ‘\’, (although you can also use ‘/’). Handling both is possible, but the code is ugly and it’s easy to make mistakes.

So our star programmer Andrew suggested abstracting things out to always use a ‘/’ character on all platforms and only convert to the native directory representation when we actually need to work with a disk. I was perfectly comfortable taking Andrew’s beautiful idea and butchering it out into the implementation you see in the file module:

https://github.com/interfaceware/iguana-web-apps/blob/master/shared/file.lua

I didn’t feel comfortable making changes to the core of Iguana’s own file APIs, so the way this library works is by overriding the built in functions that Iguana ships with and altering their behavior to use ‘/’ all the time.  I probably have missed a few functions, but I hit the ones that I needed to use.

People who use these apps aren’t likely to appreciate this beautiful internal abstraction, so I added a couple of functions which convert between the internal representation of paths and the native one. The result is that when you display paths in the GUI, they have the native representation.

So internally within these applications a windows path might be represented like:

D:/my long/directory/path/

but in the GUI you’ll see the more familiar representation of:

D:\my long\directory\path\

This change had a very positive impact by greatly simplifying the code from before this abstraction. The earlier code was trying to use utility methods to add directory separators unlike the more recent code, that overrides those methods. The more recent code is easier to understand and it works better, because when we need to add a path separator we can always use ‘/’.

It’s safe by design.