I was reading about inheritance in Tinderbox aTBRef today which spurred this question. No specific use case, just a question: if Prototypes can inherit attributes from other prototypes? Much like classes: Animal → Dog, Animal-> Cat, Animal → Human
This is more a question out of curosity and the way I think of programming and inheritance than anything else. Not a criticism or a feature request, just a question out of clarity.
This Inheritance cascade makes a lot of sense
But the question is can a prototype inherit from another prototype, like a nested inherited prototype. My initial answer is no but I am not completely sure.
Yes, prototypes can have (and thus inherit) prototypes, and this was they can be chained or treed. The case I use is to have a Meeting prototype that inherits the Event prototype. And a Weekly Meeting prototype that inherits the Meeting prototype, thus adding to a chain of inheritance. (Event → Meeting → Weekly Meeting) Or the Conference prototype can have the Event prototype, so that alongside Meeting forms a tree with Event at the trunk.
Yes, @PaulWalters, called it correctly. But there’s no error here. A challenge is that until one understands the notion of prototypes, the wider notion of prototypes and inheritance seems wildly improbable.
But what did make me sit up is the image referenced above. To me—and not because my view is ‘right’— what in that implied a prototype couldn’t inherit from a prototype? After all , it’s still inheritance.
I could perhaps have added a circular arrow on the highlighted prototype but, form experience, that would have created a different set of “I don’t understand” queries. This observation is not snarky. Rather, how does one make the uninitiated understand inheritance? What did I miss out, or, miss-explain? Anything should be explainable. My take-away is that I missed something. But. I’m unsure as to what, though very happy to resolve errors if anyone can explain.
Things aren’t obvious until they are and I thank @TomD for raising this issue, not least as so much documentation sits unchallenged and our collective leaning is the worse for it.
I have problems with the diagram in the OP (and here).
“Note local values” do not necessarily inherit from prototypes or anywhere else
“Prototypes” do not necessarily inherit from “Document attribute defaults”
“Document attribute defaults” do not necessarily inherit from “Document settings”
etc., all the way up the image
The goal of inheritance is to create a new thing that has the abilities of another (pre-existing) thing. The things that are inherited are like Legos. Making new things (notes) that have characteristics (attributes, colors, etc.) of other notes saves time and simplifies the effort of building out a set of notes on a topic.
But, as always with Tinderbox – the only way to understand something is to do it. Can I make this note look like that one? I don’t know – make it a prototype and try it? Can I make a prototype have a prototype? I don’t know – try it. Nice things happen when try outs happen.
Regarding the diagram, I think it’s fine, just add a comment or two to bring more clarity that prototypes can inherit from other prototypes. To me, this is a really important point.
I think this would help bring more clarity to the diagram
In writing/make the original text and diagrams my assumption was that too much meta-notation wouldn’t help the reader. Things I recall discarding, in the original draft were:
adding a circular arrow on the diagram—to imply the prototype might nest
adding the prototype in the diagram twice over—again to indicate prototypes might inherit
In the end, decades of “OK, that’s fine, but I don’t understand why …” follow-ups made me back off from such casual complexity.
So, stepping back to a state of not knowing, what is the simplest way of explaining this to someone who doesn’t understand inheritance or prototypes?
aTbRef is written with the intent of helping those who don’t (yet) know. Yet, inevitably, decades of writing it mean I know a fair amount about the app. Trying to remember what I didn’t know at outset is hard.
So, I accept the politely-made point that guidance currently given in this context isn’t as helpful as it might be. How then can I improve it? how do we better describe the topic (without assuming programming/CmpSci knowledge)?
The question is genuine. Grokking the power of prototypes and inheriatance is a big part of leveraging what Tinderbox offers.
†. The thanks are genuine to @PaulWalters and @TomD for drilling into this. Otherwise we slide past and don’t improve what amy be made better.
I should make clear that I expect—but don’t state explicitly in article The Inheritance Cascade —that the reader will read that whole section of articles. It is split up into small sub-articles to make the steps addressable† via Tinderbox links. But, if they do so they role of prototypes in the inheritance cascade is covered.
Still, the discussion above suggests this could be stated more clearly. But how? I’m entirely open to re-writing this section of the resource. I mainly wrote it because I didn’t think existing resources covered the whole cascade in one place—the user is left to infer the stack from different parts of the tutorials/help.
†. This is a case where more recent app designs using ‘block-level’ (i.e. paragraph within a note) have an advantage. But before writing in to demand this (feature parity!), we should be aware such an affordance rests atop a different design approach. In other words not simple/cheap to ‘just’ shim into a mature app that has a different note design paradigm.
Could we do a “Quick15” on this topic sometime, perhaps?
I’d love a refresher on the potential of cascading. I don’t use it enough, my notes are grouped/organized via UAs and I use $Prototypes sparingly; moreover they are mostly discrete and intended to help me in Map View ($Color, $-Pos, $Shape).
Would be nice to visit this in discussion, if others agree.
Sidenote: for anyone who gets the basis of how styles work in CSS, it is the same principle at wprk here. There are two parts to know:
the order of inheritance , i.e. things inherit from the item above them in the cascade. Not every item exists in every cascade, e.g. prototypes for notes not using a prototype, but inheritance skips past such missing items.
a value set, at whatever level, re-sets the inherited value of items below it in the cascade: i.e. the up-cascade value is not longer passed down the chain. The same holds true for a note, though of course nothing inherits form it: we’re simply editing the leaf at the end of the branch (which is the inheritance cascade).
Actually, it’s present all the time, so you might simply be unaware it’s there.
The most common user modification of the inheritance cascade is use of prototypes. Though many start out using them for visual modification oof notes (i.e. so distinct in the view pane) or as a way to preset a particular set of Displayed Attributes, they are still modifying the cascade.
If the app default colour for $Color is 9 (in a new doc with no prototypes), and I don’t modify anything else, all notes will use $Color value 9. If I then open the Document Inspector/system palette and edit the default for $Color to “light gray” then all items in the doc will now be light grey in colour. If I then make a prototype with $Color of “bright blue” and set half the existing note to use the prototype, then half the notes will be bright blue and half light grey. It is that simple!
Any attribute or any attribute seeded from a document setting uses the inheritance chain.
Returning to this observation:
Use it when you need to. Prototypes don’t need to do things as trivial as set colours or Displayed Attributes, it’s just where most of us start. In the same way agents & rules work fine until/unless you find the need for more nuanced control. You might find the article on Chaining prototypes (now linked from the Inheritance Cascade articles) to be of help.
I mainly wrote it because I didn’t think existing resources covered the whole cascade in one place—the user is left to infer the stack from different parts of the tutorials/help.