Andy Chambers wrote:

Hey Kenny/Frank,

How did you work out the correct order of the tk-client-task-priority?

That all arose from pragmatics, ie, solving things that kicked back during development.

I get that tk objects have to be created before they can be configured and that's why :configure appears near the end of the list but why are the :delete, :forget tasks so high up? What if something is scheduled to be deleted and configured in the same cells "timeframe"?

It sounds impossible for one datapulse to cause a declarative engine to decide something should both exist and not exist. That said...

The pragmatic history is forgotten, but normally one wants to clear the stage of things who will not be around for the next datapulse before introducing new information, lest the guys on death row get all busy with some of the new information (and new information cannot possibly want information that should not be there).

In your case, something is both coming to life and being purged in one go. Maybe a change makes the thing occur but makes a parent or grandparent thing decide to go away. In that case it probably works best to let the thing come into existence and /then/ clean it up.

But let's understand your use case a little better -- how did the birth/death conflation come to pass?

kt