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