The Inheritability of $Text when changing $Prototype

I just noticed that if a note doesn’t have any $Text and I assign a $Prototype to it that does, the prototype’s $Text gets copied into the note and isn’t updated if I subsequently change its $Prototype, whereas $MyString will dynamically update its inherited value if I change prototypes.

So it seems like $Text is subject to one-time inheritance making it quasi-intrinsic; indeed if I have $Text as a Display Attribute and explicit invoke “Use Inherited Value” it will NOT update $Text to the $Text of the then current $Prototype.

Is this a bug or the desired behavior?

It’s the desired behavior.

The (current) principle is: if there’s text, Tinderbox assumes you have approved it, and is very conservative about changing or replacing it. If there’s no text, Tinderbox can take liberties.

I’m not wedded to this, but it seems sensible.

I like it, e.g. to add to an adornment’s prototype “This adornment is about …”. Often forget to write down what it does, but it’s often been helpful.

1 Like

The only aspect that felt broken to me was not being able to manually use “Use Inherited Value” to replace the current text with the current updated prototype’s text since Text is inheritable whereas not making it updatable makes it more like an intrinsic attribute.

My current mental model is a hard dichotomy between inheritable and intrinsic but Text seems to be a little of both, so maybe it deserves to be documented under a category of InitiallyInheritable that could also apply to PrototypeBequeathsChildren since that is also a one time form of inheritance.

For a while I used to add a String attribute $CodeComment to docs and add it as a Displayed Attribute for the code prototype. But, that works for terse writing—i.e. a few words—but reality doesn’t work that way as not all things fit such a narrow ‘window’.

Better, I learned is to make a note [sic] whose text describe that prototype’s purpose. Note that user attributes have a description box allow ing you, as the attribute creator, to record it’s purpose. i’ve learned the hard way that for long-term projects/research—especially one you may step away from for months/years—to use this box to record not only the what (e.g explicit purpose) but why(why you need to create it, IOW what problem is it addressing). The ‘why’ is often far from clear at a later re-visit.

Similarly action code now allows code comments making it easier to document rules, edicts, stamps etc.

For for other structural elements (ppts, templates, link types, etc.) just make a note and store all such notes in a container out of the way, ‘back of house’ where they won’t get in the scope of queries.

1 Like

Have you tried a stamp (as I think this should be manually triggered)? Try this:

$Text = $Text($Prototype);

… works for me (just tested!)

1 Like

Perfect solution!

1 Like