9 Unsorted

• As a stylistic issue, all methods should use full record field names for their arguments.
• I am currently of the belief that all special user capabilities should be stored on objects (i.e. keys and such), primarily because any other method is just too damned easy to spoof. Here's some stuff about another way of doing it.
  • It is useful to have capablities on objects that are, more or less, automatically activated (i.e. a door that only you can walk through). MOZ calls such capabilities 'keys'.
  • Keys are stored on their own attribute on the user.
  • When a verb is call, a requestKey method is passed. Actually passing a key requires asking the user first.
  • Keys are in a dictionary indexed by ozName; ideally there would be some way to verify the ozName of the calling object.
• However, having special capabilites on objects (which are presumably carried) leads to some issues with things like a dragon who doesn't eat anyone wearing the Gauntlet Of Might, or whatever. Ways of handling this are below. I have not picked yet, although I have a bit of a preference for a 'wear' verb.
  • Verb transparency to objects in inventory, which could cause problems if you pick up the wrong thing. But this could be selectable, i.e. some objects are allowed to be verb-trasparent. The easiest way would be a 'wear' command, such that objects that are word are checked for verbs.
  • Extensible verb lists (i.e. an attr?) in which an object field is part of the verb definition. This way the Gauntlet of Might would add a verb to the *player* (with permission, of course) called 'challengedBy'. Calling challengedBy( arg1: <the dragon in question> ) returns a value that causes the dragon to calm down.
• This was in the class Parser section. I was smoking crack.

  Note that the verb call can immediately thread off, and should almost always do so if any non-trivial computation is done, since output is handled by an Oz port. This will be particularily important when in-game thread management is implemented; threading off will allow the player to kill threads if necessary, as commands can still get through.

  There is no way to get a list of threads in Oz, so what needs to be done at some point is to hack the parser object to thread off all verbs and save their thread ids on the player object, so that the player can kill them.

• I have no idea where to put this. Movement of an object is three seperate things, in terms of capabilities: changing of where the object's location attr points, and changing the contents list of the before *and* after objects. Therefore, capabilities on three objects are involved. This should be discussed, both as a capability example, and an implementation detail. Maybe it's time for implementation notes?