Welcome, Guest. Please Login
Tinderbox
  News:
IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).
  HomeHelpSearchLogin  
 
Pages: 1
Send Topic Print
So why does this happen? (Read 12763 times)
The_Gut
Full Member
*
Offline



Posts: 4

So why does this happen?
Aug 09th, 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.
Back to top
 
 
  IP Logged
Mark Bernstein
YaBB Administrator
*
Offline

designer of
Tinderbox

Posts: 2871
Eastgate Systems, Inc.
Re: So why does this happen?
Reply #1 - 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....
Back to top
 
 
WWW   IP Logged
The_Gut
Full Member
*
Offline



Posts: 4

Re: So why does this happen?
Reply #2 - 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.

Thanks

Richard
Back to top
 
 
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: So why does this happen?
Reply #3 - 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.
Back to top
 
 

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
The_Gut
Full Member
*
Offline



Posts: 4

Re: So why does this happen?
Reply #4 - 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.

Richard
Back to top
 
 
  IP Logged
Mark Bernstein
YaBB Administrator
*
Offline

designer of
Tinderbox

Posts: 2871
Eastgate Systems, Inc.
Re: So why does this happen?
Reply #5 - 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!
Back to top
 
 
WWW   IP Logged
DerikBadman
Ex Member




Re: So why does this happen?
Reply #6 - Jan 13th, 2008, 1:29pm
 
This is fascinating. Somehow I missed the addition of prototypes bequeathing their children.
Back to top
 
 
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: So why does this happen?
Reply #7 - 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.
Back to top
 
« Last Edit: Jan 15th, 2008, 7:02pm by Mark Anderson »  

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
maurice
Full Member
*
Offline



Posts: 81
London, UK
Re: So why does this happen?
Reply #8 - 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.
Back to top
 
 
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: So why does this happen?
Reply #9 - 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.  Smiley
Back to top
 
 

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
Pages: 1
Send Topic Print