- Mac OS X
12 July 2012
Continuing our journey to new-but-not-so-new-and-broken-anyway practices in personal computing, we'll incorporate another layer of Sainte-Force to the age-old file system. Some time ago, we added links, but doing this throws in a new kind of object (those links) that requires more integration in old programs, in ways that could sometimes be better done. Here we take a different approach: we want to keep playing with the same old objects (files, folders, packages), but give them new capabilities that don't alter the current assumptions that all other programs make about them.
You could say that it's the kind of reasoning that led to multiplexers and tin cans, but these two turn folders into packages, so it's not the same thing. Porkcuts is a more accurate example of the approach I'm talking about. With Porkcuts, files still are files, folders still are folders, but they afford new superpowers that depend on where and what they are. Now, there's an other example I wish to present you.
Duplicating a file or a folder is a common practice. One of the reasons to do so is to use the file (or folder) as a template or stationery pad (gather several of them an you get a transfer sheet). However, duplicating doesn't keep any relationship between the original and the duplicate: they're condemned to evolve independently. It's not always what you want. A web site is made of many pages that often contain the same title. What if you want to change the title after hundred of pages have already been made ? Imagine you want to build such a site. You could, for instance, devise a template that contains the common things in all your pages, and duplicate it each time you want to create a page. The duplicate is then filled with your information, keeping (or not keeping, depending on how special your page is) the common title that originates from your template. Because you only duplicated things, you can't modify the title in your template and have all the other pages automatically modified.
Those kinds of dynamic templates you start to spot behind this example can be done in multiple ways, but none of them exists in current mainstream desktop software. Dynamic templates would be a natural side-effect of having links and transclusion in a computer system. In the world of files and folders, you can meet a poorly integrated wannabe in the person of aliases or symbolic links.
A second way of having dynamic templates can be found in prototype-based object-oriented environments. Here, the world is made of objects. These objects have several slots, which can represent either information or behavior. In some versions of this world, there can be a special slot called parent or prototype which refers to another object. If object A has a prototype slot to object B (we say that B is A's prototype), then it alters the way we look for slots in A (the mechanism is called delegation). Imagine that A has slots parent, count and fruit, while B has slots vegetable and count. When you search for A's vegetable slot, you find nothing, but because B is A's prototype and B has one, you get B's vegetable slot (if this slot specifies a behavior, it'll be done in the context of A). Now, if you search for A's count slot, you'll get A's count slot and not B's, because that's the first we found (that situation can be called overloading). Slots that are present in the prototype still can be different in the offshot. In such a prototype world, those rules allow similar objects to share behavior while still retaining some uniqueness. There could be a web page prototype, and hundreds of individual web pages using this prototype. If things are done correctly, modifying the prototype's title would impact on every other web page using this prototype, and the world would be happy.
The Sainte-Force software presented today is an adaptation of the world of prototypes to the world of files and folders. Obviously, we can't think of files as objects, because objects have a common internal structure (slots) and files don't necessarily have any structure. However, folders are perfect candidates. They have a structure, their contents, that's a list of files and folders. A file or folder name in that contents is a slot, a reference to something that can be a file or another folder. Following this dubious mapping, we can see that the file system lacks a way to tell that a folder is a prototype of another folder. And that's what Sharkhetype is all about.
Sharkhetype is the same kind of program as Porkcuts: you run it once, possibly at login, then you forget it and either it enhances your productivity or crashes your computer. But, as we discussed earlier, it does radically different things. Instead of pouring some files and folders in a programming bowl, we put some programming into files and folders.
When Sharkhetype loads for the first time, it creates a folder in
~/Library/Prototypes. Each folder in this one (not in subsequent folders) can be used as a prototype. For instance, create the prototype
ProgrammingProject and put some files into it. There are various files that are useful in any programming project:
Changelog, you name it ! These prototypal files can be filled with some boilerplate information, like copyright disclaimers or cleaning commands. Once you're ready to go, just create a folder anywhere in your computer (but nowhere outside your home directory), and make its name end with the extension
.@ProgrammingProject. In the end you'll get a folder like
helloworld.@ProgrammingProject. Sharkhetype will immediately recognize this extension and associate it to your
ProgrammingProject prototype. It'll copy its files to your
helloworld folder and work hard to ensure that any modification in the prototype leads to corresponding modifications. However, overloaded files will be kept as is. Like this, you can create as many programming projects as you want, simply by creating an empty folder and giving it the proper extension. Changing the prototype is as easy as renaming the folder. As prototypes still are folders, they can also have prototypes. You can create heavy prototype chains and Sharkhetype will still work, as long as you don't try to create loops, where for instance A is the prototype of B, which is the prototype of C, which is the prototype of A. Sharkhetype detects some prototype loops, but maybe not all of them.
Behind the scenes, Sharkhetype uses Spotlight, so it won't work if Spotlight isn't activated or doesn't index the folder you're working on. Although it should work on Snow Leopard, I've only tested it with Lion. Take care of what you do, because it messes with the file system, and deliberately creating a prototype loop may result in high CPU usage and low disk space in quite a short time. Of course, this program is provided without any guarantee, and responsibility is yours entirely.
To draw a parallel with ancient dualist philosophies, Porkcuts and Sharkhetype are the yin and yang of file management. Porkcuts deals with containment relationships, where things belong to other things, and Sharkhetype deals with inheritance relationships, where things are more specific kinds of other things. The two have different dominant characteristics: Porkcuts is related to behavior, programming; Sharkhetype to state, folders. But there's a bit of folders in Porkcuts, as there's a bit of programming in Sharkhetype. All you need to know is that the two combine perfectly into a perfect whole. Enough crackpot theory for today !
- Download Sharkhetype 1.0 (Mac OS X 10.6+)
Looking forward to hearing from you,