Printed dictionary (was Re: send mouseup to control)

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com