executionContexts

Dar Scott dsc at swcp.com
Sat Oct 14 16:49:07 EDT 2006


On Oct 14, 2006, at 12:46 PM, Richmond Mathewson wrote:

>   Just tried to find "executionContexts" in the
> documentation for DC 2.6.1 and RRMedia 2.7.2 and found
> nothing.
...
>
> I wonder why there seems to be some resistance to
> documenting these things?

I try to refrain from insisting somebody gives me something that I  
didn't buy.

As a product Revolution does NOT have executionContexts except maybe  
as a reserved word of some sort.  This is not an underdocumented  
feature of the product.  I did not buy executioncontexts.

It is a feature of the engine in some sense.  It is used by at least  
one library and maybe the IDE, but those are RunRev intramural.  By  
the use being intramural, RunRev can tweak the behavior as needed  
without legacy concerns.

Given that, things get muddy.  Bugzilla 1242 is an enhancement to  
make exectionContexts a feature.  It is one of only 21 enhancement  
suggestions that have been marked not-a-bug.  Some of the discussion  
was related to the ability to make callbacks in the same style as the  
sockets capability.  That has been specifically requested in bz 1954  
(and 2839) with the suggestion that a new function be added.  This  
function could be built out of executionContexts (even if the bug I  
mentioned is fixed), but it would be based on something that might go  
away in the future, so I'm hesitant to do that for deliverables.  The  
executionContexts could also be handy in throwing something that  
looks just like engine error or rethrowing an engine error so that it  
looks just like it was never caught (see bz 3757).  These commands  
built on executionContexts, too, would be based on a nonfeature.   
Providing these more specific functions and commands would make  
blessing executionContexts less important, but I'm sure others would  
come up with uses I have not mentioned.

Some future version could potentially make that a supported feature.   
That would have a cost for RunRev.  It would have to be documented.   
It then would receive bugzilla submissions, such as one for the bug I  
mentioned earlier.  There would be the cost of support in explaining  
to use that we are using it wrong.  It would also mean that if they  
need some variation, they would have to build a new private property  
or function.

Dar




More information about the use-livecode mailing list