While on the subject of classes, I've run into a number of language limitations. One, as mentioned in another article, is an inability to redirect actions. Which means that going through a locked door would require the player to unlock and open the door manually every time, and I didn't even want to think about having a known key
mechanism. So instead I made a rudimentary door class and allowed players to simply pass the exit checks silently if they are carrying the right key. There is also the fact that object properties in Alan can't have a null value, so a door *must* have an "other side". But that eliminates an entire class of potential programming bugs, so.

(On a related note, you can't define a "catch-all" action for verbs. You *can* group verbs in action declarations if their syntaxes are compatible, but you can't say "for any other verb, do this". So no Distant or Unimportant classes for you; the amount of boilerplate required would be beyond absurd. That's also because of the strong typing.)

Another problem is that you might want to open and close objects that aren't doors, so those verbs really have to be defined on the Object class. And that caused a problem with the Device class, where I did the same with "turn on/off". Which in turn required me to use the "only" verb qualifier... and that meant that "after" refused to work
on an instance of the same class in the game. Certainly, using "before" to schedule an event had the desired effect, but still.