James Hale wrote:
> In following them discussion on execution contexts Richard wrote:
>> The executionContexts is documented, though in all fairness that
>> Dict entry includes a note about not relying on the format of its
>> contents.
>
> ...this morning the printed dictionary arrived! 🎉
>
> So I looked up executionContexts
>
> Where I read...
> '' A common use of the executionContexts is to obtain the name of the
> object and handler that called the current handler, this information
> is available as line -2 of the executionContexts."
>
> BTW there was no mention of any caveats in using this property.
In v6.7 and later (possibly earlier too; I didn't check any version
prior to v6.7), the Dictionary entry for the executionContexts includes
this note:
Important: The value of the executionContexts may be
changed in future versions of LiveCode, it is not
recommended to write code that depends on its contents.
The web version of the Dictionary, though reportedly a few versions
behind more recent versions (to the confusion of a few forum readers),
also includes that note:
https://livecode.com/resources/api/#livecode_script/executioncontexts
What version was used for the printed Dictionary?
All that said, I still feel comfortable using the executionContexts,
though sparingly and usually with an easily-searchable flag comment* in
case I need to update it later.
After all, consider the fate of every Cocoa API call, or what happened
to Python users moving from v2 to v3, or so many other things in the
programming world. Stuff changes. If this changes too it won't be all
that different from anything else we need to contend with. :)
LiveCode has a far-better-than-average record for maintaining backward
compatibility, and for responsibly managing change. In the rare case
when a token is deprecated or its behavior is changed, it's usually
called out in bold read type in the Release Notes. So if that ever
happens, I'll know about it early on during the DP builds, and can find
the few places I use executionContexts easily enough.
Where factoring into separate handlers is the best fit for the problem,
it's the best fit for the problem; a different solution like
executionContexts wouldn't be the best choice in such cases anyway.
But if I avoid a working solution solely out of fear of possible future
change in an API, in a world where the only constant is change I'd never
write any code. :)
* FWIW I often flag code with three tags for easy searching, using a
pattern Ken Ray and I call "Hmmm, Bang! What?":
"Hmmm":
--# Something worth drawing attention to for future versions,
perhaps for later optimization, or just an unusual construct
possibly worth reconsidering down the road.
"Bang!":
--! Something that MUST be addressed before release! Used for
very unusual blocks that should be reviewed for
revision before shipping. In the heat of the moment we
may need to patch something together in one place in order
to finish work in another part of the system; this flag
allows finding those so we don't ship with those in place.
"What?":
--? Something that should be addressed as soon as time or
opportunity permits, but not show-stoppers (which would
use "--!" as above). Sometimes this may be a workaround
for a bug in the engine, and if so I'll usually include
the bug number so I can refer to it later. Or it may be
a kludgey solution that works well enough for now but
may be brittle or have potentially complicating implications
elsewhere down the road.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
