I’m thinking just now about composite objects – Tinderbox notes that are made up of several notes.
Alongside inheritance, composition – building objects from smaller objects – is one of the key ideas in object design and knowledge representation. Of the two, inheritance gets attention but composition is the workhorse: beginners are always reaching for complex inheritance chains while overlooking nice designs composed of a handful of cooperating objects.
Here’s an excerpt from my Hypertext 2016 conference notes about one excellent paper presented by Thomas Schedel. The whole thing is really one composite, a ConferencePaper. Inside, we see some smaller composites, too. There’s an author/title pair, which all conference papers have but which things like fiction readings also have. There are horizontal lists, vertical lists, and perhaps some lists of lists. There are notes about questions I had during the talk, things I wanted to ask Dr. Schedel about; he and I later had an extraordinarily productive one-on-one in the lobby of Dalhousie’s collaborative health education building – a lobby nicely designed for this sort of collaborating.
Many questions remain. Do we tell Tinderbox that “this is a conference paper”? Or do we build a prototypical ConferencePaper and ask Tinderbox to discover conference papers automatically? Suppose we have a ConferencePaper that doesn’t quite fit our definition: how can we relax the definition without getting bogged down in some sort of generalize Backus-Naur notation? (Trust me on this: when Tinderbox users are trying to keep up with a speaker in a scientific conference, they do not in general want to be juggling BNF simply in order to get what she's saying into their notebook!)
What is “ConferencePaper,” anyway? It’s less than a Class or a Type, but I think it’s more than a Name or a Label. I wonder if there are lessons from Duck Typing that I should study, or perhaps something from Programming By Example? Ideas? Email me.