A very common thing to want to be able to do with a Set, is to have some way to access its members in a convenient way.

In Relational Databases, queries can be made that match on specific column values of a table.

SELECT * FROM MYTABLE WHERE NAME='CUTTHECRAP'.

This will search a specified table for any rows where the 'NAME' column has the value 'CUTTHECRAP'.

GPO does not have "tables", but it does have the more generic "set" - more generic since an entry may be in more than one 'set'.

Now, it is an easy enough thing to write some code to search all the members in the set and find those with a specific value against a specific property. But this is a pain - and it might be slow.

Relational Databases provide structures called "Indexes" that are maintained for specific columns - or sets of columns - for each table. If the indexes are chosen well, then the process of querying the contained data is much much faster.

Classifiers

GPO allows Classifiers to be defined over any LinkSet. These can be declared in advance - before the LinkSet has been created.

A Classifier object can be retrieved directly from a LinkSet and used to lookup values in that set. Typically a classifier might be declared as follows:

objectManager.declareClassifer("parent", "name");

Meaning that for any LinkSet created for a "parent" property, the objects in that set will be classified according to their "name" property. So :

GPO ctc = myTable.getLinkSet("parent")
  .getClassifier("name")
  .get("CUTTHECRAP");

should be seen to be similar to the global relational query above.

The nice thing about classifiers, is that since you are able to get hold of them directly you can ask all sorts of interesting questions - like:

...and more besides.

With this kind of behaviour, it is relatively straightforward to build interfaces that navigate the classification structures directly - the kind of thing that requires multiple parallel table structures in a relational system. And that would create enormous data integrity problems.