Two Great Tastes

(LJ is borked, so I'm going to try posting this via DW and see if it crossposts properly.)

I smell a project coming on.

For quite a long time now, I've had the ProWiki technology sitting there, gathering dust. For those who are new to this story, ProWiki is a wiki system that I wrote the better part of 10 years ago now. In one sense, it's quite primitive: it's based on UseMod, one of the very first wiki codebases, is written in mediocre Perl 4, and looks extremely plain. But at its heart, it is quite radical, because it's actually an object-oriented database masquerading as a wiki. Each page is treated as an object and can have properties; there's a concept of inheritance so that you can have well-defined semantics; there's even a horrible but effective query language so that one page's content can actually be a query into content defined on other pages. The result is that it's excellent for certain use cases -- in particular, for LARP writing, which is what I developed it for in the first place.

The reality, though, is that ProWiki is way too damned primitive in many ways, and the name (which stands for "property-based wiki") steps on one that an unrelated group turns out to be using. And the idea of putting properties on pages has been used in a few other systems -- to a limited degree in Twiki, and to a much better degree in the sadly-unstable XWiki. None of these really hum for me, though, so I've long been wanting to start again from scratch. That project has long been known as Querki (for "queryable wiki"). I have the domain sitting there, and pretty extensive design and requirement notes. I haven't done anything with it, though, because building websites is such a pain in the ass.

But now along comes Lift, the Scala web framework. I know Rails well enough to know that it is still a headache, but Lift is terribly appealing: as is usual for the Scala community, they've stepped back and really thought things through. Today I stumbled across the Seven Things page, which underscores this: it's simply a list of common web patterns that are a pain in the ass to implement in most frameworks, but dead-easy in Lift -- most of which are crucial for Querki.

So I think I'm sold. I've been looking for a good excuse to write a serious project in Scala ever since CommYou got aborted in mid-implementation, and this looks like a fine opportunity. Not that I have any free time at all, mind, but I think I need to start playing with this, because it looks like altogether too much fun...

Extensible enumerations

(This one's just for the programmers, but it's not as opaque a topic as usual.)

So in the course of thinking about my last post (about Querki), I happened to look at my desired feature list. And I was reminded of one of those bugbears of most programming languages: enumerations.

Here's the thing: what I want, much of the time, is the ability for subclasses to *extend* enumerations. The most common use case is return codes. I might have a base class that implements the concept of return codes, and includes an enumeration of the basic codes for success, warning, failure -- generic stuff. As I add subclasses with more precise functionality, I want those subclasses to be able to add more-precise return codes, that describe the results in more detail.

But I can't do that, at least not safely, in any language that I'm thinking of offhand. The thing is, I wind up with two possibilities. Either the return code is something like a raw integer under the hood, so it's totally unsafe and not really type-checked -- this allows for risky code. Or the enumeration *is* strongly typed -- in which case, I can't add values. Why not? Because adding values is effectively *extending* the type, rather than *specializing* it, and that's a no-no in any decent OO system. It implies that a subclass could add values that don't exist in the parent, so code written for the parent doesn't necessarily work with the subclass -- a violation of the basic principles of OO.

When I think about it, though, it occurs to me that it's easy to fix this: just redefine my terms. What I really want is the idea of *hierarchical* enumerations. That is, the base class defines "success" and "failure", but no details. But this is precisely what OO is good at: what I want is to think of those success and failure values as *classes*, which I can then subclass. So I want to be able to define a "subclass" of the enumeration that adds specializations to the existing values. So instead of tacking "Null pointer" or "Not authorized" to the end of my enumeration, I should be thinking of them as specialized values of "Failure". That follows good OO principles, and seems like it would work well.

Does anyone know any languages that formally do this? I *can* do it in Scala decently well using case classes, but that's not quite optimal: I'd prefer a syntactic construct that is more explicit about this notion of a hierarchical, extensible enumeration. But I don't think I've ever come across one.

Anyway, I need to chew on this further. It's directly relevant to Querki, because I want to add a formal concept of enumerations there, and it needs to be exceptionally rich in order to cope with the use cases. (Since Querki is going to be used for world-building, I need a lot of schema flexibility.) I may well apply this concept there...