OiRc-0008 A question of semantics

As I am reviewing my class notes for my system's class, I am struck by the realization of the thought pattern underlying the difference between the common view and my view of just about everything but of OiRcs in particular.

It begins deep in the use of English. Being bilingual has its uses after all.

In English there is no easy way to describe relationships and there are no words to describe them. Thus A<->B becomes two sentences:

• A relates to B, and

• B is related to A.

The very words used to describe the relationships are terms like 'has,' 'owns' and 'is a member of,' 'belongs to' and so on. There is no terms in there for 'under what circumstance' and no description of cardinality, mutability and optionality.

And therein lies the problem.

Apart from the awkward switch in tenses depending on the direction one is looking (A to B or B to A) and the generally undescriptive term used to describe the relationship, the relationship is not described first. Instead it is a verb sandwiched between two mouns and it needs to change tense depending on how one is looking at it.

This is wrong. Just plain wrong.

I propose that the relationship be instead described by a noun, not a verb.
Thus A 'owns' B becomes 'has a' relates one A and many B.

Since 'has a' is not an appropriate lin guistic term, it needs to be replaced by some meaning forl word, usually this will be a noun.

Thus Library has Members becomes Membership relates One Library and Many Entities. (I am skipping a head of myself a bit since Entities could be described as People, and Library is a Role that an instance of Entities is playing.

Playing is itself a relationship between a Role and an Entities. This means that the same entity can a lender and a borrower be. (With apologies to Hamlet, or at least to Shakespeare.)

This brings about an interesting condition: Recursion.

Thus Membership relates One Library, which is a Role an Entity can Play, and Many Entities. Relationships can recursively relate other relationships to each other or to object instances.

OiRc-0007 Properly untangling the Gordian knot

Regardless of however many levels of Relationships lie between the Objects, you still need a way to array all of them in an orderly fashion.

Topological sorting of all of the objects is the only way to accomplish this, sorting objects topologically close to their owners. (You would probably want to add methods to disambiguate or perhaps sort the objects.)

In Smalltalk this is probably best described by:

 topologicalSort: aDAGInADictionary
  "input aDAGInADictionary -> a Dictionary of all the nodes in the system
   it associates a node label with a collection of its dependent nodes"
 | virgins nodesInReverseOrder visitBlock |
  virgins := aDAGInADictionary keys.
  nodesInReverseOrder := OrderedCollection new. "unless you're sorting 'em"
  visitBlock := [:aNode   |
      virgins remove: aNode.  "another one bites the dust"
     (aDAGInADictionary at: aNode) do: [:anArray  |
          anArray do: [:anotherNode  |
             (virgins includes: anotherNode)
                  ifTrue: [visitBlock value: aNode]]].
      "add me after all of my successors and their successors, etc.
      have been added"
      nodesInReverseOrder add: aNode
     ].
   aDAGInADictionary keys do: [:aNode |
      (virgins includes: aNode)
          ifTrue: [visitBlock value: aNode ]].
^nodesInReverseOrder reverse "but not if they're being sorted"

Simple and elegant, no?

Of course how you define the Dictionary which is the parameter to the method is everything.

It must consist of entries associating each the Objects to which each node entry to which it is related.

Since I hadn't fully evolved the concept of Relationships back when I was writing this, it is incomplete and in I would be in need of a patron to keep me alive while I untangle the web we weave, when first we practise to reveal.


Suffice it to say that each Relationship from one Object to another should be represented as a fully formed line instance, arrayed between each object.

I have given some thought about how these should be drawn and I will reveal it in a few days, after I get out of school and have more time to devote to the answer.

OiRc-0006 Cutting through the thicket

If you're paying any attention, you've noticed that I used to be far more timid in my promotion of Relationships.

The example code in the previous entry has Relationships but it doesn't have nearly enough.

I still had the concept of radixes into 'code tables' as

• radixTable( aTableSymbolString, aLanguageRadix) answer any radixed value sets (array of labels) to associate aTableSymbolString, aRadix with a string value. The defaults are hardcoded English and internationalization will be handled by an internationalizationTable where sets named aTableSymbolName are stored in the table as aTableSymbolName, languageRadix, setRadix => aString.metadata
• slotLabel( aLanguageRadix, slotName) answers a label for a slot named aSlotNamed in language aLanguageRadix. The defaults are hardcoded English and internationalization will be handled by an internationalizationTable where slot named className, slotName, languageRadix => aString.metadata

This was an error that I can only attribute to the depth of a habit of embedding references to other objects in other objects.

Its one thing to being able to draw a distinction between business object data models and another one to fully realize that system design should be made up of 'a few rules, ruthlesly applied' (I think thanks or apologies are due to Alan Kay, the founder of Smalltalk, for that quote but I've just Googled it and I seem to be quoting myself again.)

The habit was hard to break. It took me years so I don't expect to encounter it in the wild for a while yet.

Part of my problem was that I knew that dis-embedding the references to radixes would lead to much a more complex schema definition.

It would be harder to visualize, harder to manipulate and harder to implement systems based on this vision, some might call it a near hallucination, of Objects and Relationships.

I will revisit my notes from my exploration of the complex and wonderfully normalized database schema that revealed 750+ Objects and 1,200+ Relationships. But if, as I suspect, it also made the distinction between Business Objects and radixes into code tables, the 750+ objects was infact an underestimation.

More in the next blog entry.