Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com)
Tinderbox Users >> Agent, Actions, Rules & Automation >> So why does this happen?

Message started by The_Gut on Aug 9th, 2007, 10:30pm

Title: So why does this happen?
Post by The_Gut on Aug 9th, 2007, 10:30pm

I create a note to be a container. Its called Wants.

I make it a prototype.

I set an onadd action of Prototype=Wants

I create a note that I want to add to the container Wants. Its titled Phantom Tollbooth. I drag it and drop it onto Wants.

Two identical Phantom Tollbooth notes get created, with one being the child of the other.

It seems to be related to Wants being a prototype, and setting the prototype equal to itself. I got around it by creating a container just for prototypes, and not making the container a prototype.

But, in the interest of learning, I want to know why it did this.

Title: Re: So why does this happen?
Post by Mark Bernstein on Aug 9th, 2007, 11:01pm

Hi, Mr. or Ms. Gut!

In Tinderbox 4.0, prototypes bequeath clones of their children (and adornments) to their instances.  This lets you do lots of things that were difficult in prior versions, but your specific example -- a container that makes its children use the container as a prototype -- is problematic.

When you think about it, though, a container is seldom a good prototype for the things it contains.  An orange crate isn't a prototypical orange.  A wine bottle isn't prototypical wine.

This is easy to fix: separate the prototype from the container.  (In Tinderbox 4.0.1, you will be able to turn off cloning of inherited notes by setting PrototypeBequeathsChildren to false, just in case you really prefer the old behavior)

Note to computer scientists: When we originally planned Tinderbox, we adopted the (fairly) radical scheme of prototype inheritance to avoid REQUIRING class objects which, as you all know, tend to confuse people who are studying computer science. We discovered, over the years, that most people tended to drift toward using specific notes as prototypes, rather than using (as we expected) an arbitrary instance as an exemplar.  In consequence, Tinderbox 4 tends to favor using a dedicated note as an object.  In detail, the only penalty to the change involves the Composite pattern, where a note is interchangeable with a collection of notes. When this occurs, Tinderbox 4 requires a refactoring so the prototype note is distinguished from a specific container; since the refactoring is easy and costs almost nothing, the change appears to be inconsequential.  

The use of prototype inheritance in Tinderbox would make an interesting study for an ambitious student....

Title: Re: So why does this happen?
Post by The_Gut on Aug 10th, 2007, 6:40am

Thank you!

I almost grasped the answer. If you could explain it one more time, in a different way perhaps, it would be appreciated.



Title: Re: So why does this happen?
Post by Mark Anderson on Aug 10th, 2007, 12:00pm

In simple terms, the first part is like this.  From v4.0.0, notes with Prototypes inherit the prototypes note's children too. Thus A prototype Project might have child notes Contacts, Deadlines and Milestones. Setting a new note ACME bid to Prototype=Project would cause ACME bid to gain 3 child notes, courtesy of the inherited prototype.

In your case, Wants has no children. Fine.  But when the Phantom Tollbooth is added as a child of a prototype, any note with the Prototype value of Wants now gets a new child called - you've guessed - Phantom Tollbooth.

I fear we beta testers fell down on the job and most likely for the reason Mark alludes to, that more seasoned users tend to graduate to putting most/all prototypes of in a container of their own and not mix them with general content as you're doing**. So you're seeing the law of unintended consequences at work here and a fix is en route for v4.0.1 in due course, via an attribute to control inheritance of children. In your case you'll set it to false and that pesky extra child will magically disappear. Until then, I'm afraid you'll need to avoid using prototypes as containers to avoid the issue you report.

** that's not a rebuke at your usage. When using TB to manage emergent structure, taking existing content notes and making them prototypes is perfectly sensible behaviour.  Anyway, the upcoming fix will make this all go away.

Title: Re: So why does this happen?
Post by The_Gut on Aug 10th, 2007, 2:32pm

Thank you.

Actually, thats the way I normally do it - put the prototypes in their own area. I was experimenting this time with a different way of doing things. I've been playing with Journler, and this was similar to one thing it does. If you have a smart folder there set to collect notes with a "wants" tag, and you drag a note and drop it on that smart folder, it adds a wants tag. I was playing with something similar here with Tinderbox.

I'm not sure what the advantage of this new way is - it would be nice to have an example where this makes something easier than the old way, but I'll take your word for it.


Title: Re: So why does this happen?
Post by Mark Bernstein on Aug 10th, 2007, 2:42pm

1) Suppose that you need to plan a weekly meeting for your project team.  Each week, you want to make a new agenda; it uses Meeting and a prototype.  But inside each Meeting, you'd like to have a bunch of notes:  participants, topics, action items, minutes.  Now, you can arrange for all those items to be cloned whenever you start planning a meeting.  And your actions or rules all know, for example, that a sibling of a "topic" in a meeting will include "minutes".

2) Suppose you are taking notes at a conference.  You make a new note for each session.  But inside that note, you want a bunch of adornments -- each with a distinct color, size, and appropriate rules.  Now, whenever you make a new Session, you can get all those adornments instantly. No muss, not fuss.


If you want the behavior from Journlr, just use an OnAdd action to set an attribute directly. OnAdd: Tags = $Tags+"exciting;new;amusing;pseudonymous".  Setting the prototype is powerful, but it's not the only thing you might want to do!

Title: Re: So why does this happen?
Post by DerikBadman on Jan 13th, 2008, 1:29pm

This is fascinating. Somehow I missed the addition of prototypes bequeathing their children.

Title: Re: So why does this happen?
Post by Mark Anderson on Jan 13th, 2008, 2:57pm

FWIW, the feature is new as from v4.0.1 and it also defaults to 'true' - i.e. behaviour as before. So, if you don't read the per-release release notes (or aTbRef!) you might easily miss it. Remember release notes (from v4.0.0) can be opened from the app's Help menu.

Title: Re: So why does this happen?
Post by maurice on Jan 15th, 2008, 6:54pm

Actually, it defaults to the new behaviour, so you have to switch it off if you want life to continue as before.

Title: Re: So why does this happen?
Post by Mark Anderson on Jan 16th, 2008, 6:41am

It depends.  The default equivalent pre-v4.0.0 would be false. It was v4.0.0 that introduced the ability for prototypes to also create children, so the equivalent v4.0.1 default would be indeed true. However...

By the Law of Unintended Consequences it became apparent after v4.0.0 release that Prototypes with children  always adding those children via inheritance might not be ideal  - especially in legacy TBXs where prototype status had been given, through emergent structure, to notes that were containers yet whose children were unrelated to prototyping requirements. Thus the new system attribute PrototypeBequeathesChildren was added in v4.0.1.

So I guess it depends on where you start: pre-v4 only you might expect PrototypeBequeathesChildren to default to false but if you'd upgraded through v4.0.0 the expected default would be true.

Take your pick! I hope that makes it clearer.  :)

Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com) » Powered by YaBB 2.2.1!
YaBB © 2000-2008. All Rights Reserved.