Muq thinks of objects primarily as a set of keyValue pairs: as tables of named properties. Thus, we might have an object named 'Kim':
Name: Kim Age: 12 Weight: 64 Hobby: Drawing Grade: 7 Marbles: 12 Bedroom: Messy
As you can see, a Muq object can be visualized very nicely
as a two-column table. Given any key, such as "Name",
Muq can easily give you the corresponding value ("Kim").
(The reverse is not true: Given a value, Muq cannot quickly
find the matching key, and in fact there may not be a unique
matching key, as with 12 in this case.)
Muq tries very hard to make every bit of information in the system appear to be the value of some key on some object.
By presenting all information in the metaphor of keyval pairs on objects, we hope to be able to build powerful, general object inspection and editing tools and then get lots of mileage from them by being able to apply them to all of the information in the Muq database.
In pursuit of this level of generality, Muq allows both keys and values to be (almost) any value whatever which Muq knows how to represent. (The exceptions are a few obscure values used internally which users are never supposed to see, such as the internal "I can't find that key!" value.)
Go to the first, previous, next, last section, table of contents.