Explicit Variables again

[Richard Gaskin]

Mark Wieder wrote:

> Richard-
>
> Thursday, October 18, 2012, 8:51:46 PM, you wrote:
>
>> Remember that LiveCode is dynamically compiled - the only copy of a
>> script stored with a stack is the source copy, not any tokenized
>> version.  So whenever you open a stack, as part of the unpacking its
>> scripts are dynamically compiled - and that's when the compilation error
>> will occur.
>
> OK - I see the difference. I've never considered turning explicitVars
> on from the message box. The message box is a weird enough critter
> that I wouldn't be surprised by unexpected consequences (OK - I
> realize that's an oxymoron, but I can live with that).

My issue with LC's Message Box is that it's always in palette mode. 
MC's is modeless, and the more I use Terminal the more I've come to 
enjoy having the MB occasionally sized larger and always layerable with 
my other windows.

So a while back when I had a free Saturday I started work on my own MB 
replacement, and these days it's much easier to do a graceful 
implementation because we now have the messageBoxRedirect global 
property (thanks for that one, Kevin - I'm making good use of it).

At the time my main motivation was just to have an MB I could use as an 
optional plugin in standalones but limited to specific commands in case 
I chose to make it available for customers, but the more I got to using 
it the more I found it simpler for day-to-day work in the IDE than LC's 
mouse-driven MB UI (when you're typing, you're typing).

I've since added a bunch of shortcuts I use all the time, like listing 
globals vars and props, and stack lists, and the message path, and other 
stuff, and then I started down the road of implementing a few shell 
calls like "ls" and "cd" - and of course now the challenge is to stop 
doing that so I can just post it for others to use.  I have an update 
for devolution in the works that'll include it once I get a few client 
things out of the way.  It'll be MIT licensed so folks can tear it apart 
and make their own if they want.


> But I've had explicitVars enabled from the preferences menu for years
> and never had a problem. The IDE stacks are notoriously not
> explicitVars-safe, so you'd expect there to be issues with them if
> there were any problems with running in mixed mode.
>
> The only "issues" I've had are when trying to compile someone else's
> stack, plugin or no, that doesn't have declared variables.

That's the great thing about LC's current implementation in their IDE, 
one of the areas in which I'd say it's a cut above MetaCard:

In MC, being close to the engine as it is, explicitVars is truly a 
global property, and will require that everything you run has been 
written to accommodate it.

In LC we have greater freedom in the sense that we can turn it on for 
our own scripts while still using stuff from other people that doesn't 
account for it.


Some history trivia for those who might care:

The explicitVars global property was added for SuperCard compatibility 
back in the late '90s.   SC was the first xTalk to have implemented 
this, and I suppose that Raney, with his degree in CS focused on 
compiler design, found it appealing, so unlike so many other SC- and 
HC-specific compatibility tokens added as mere non-working stubs, this 
one was added with full functionality.

But how did SC come to have explicitVars?

Back in those days the lead engineer for SuperCard was Gary Poppitz, a 
man well versed in C and 68k Assembler.  As far as I know no user had 
ever requested it, he just felt it would be useful and put it in.

After he added that to SC I wondered if perhaps the benefit might be 
compiler optimization, so I did some benchmarking.   But on the 
contrary, I found that running with it turned on actually made script 
execution measurably slower than without (not by much though, maybe <5%, 
and I've seen no difference in speed with LC's implementation, though 
it's been years since I've benchmarked it).

So I asked Gary, "Why was explicitVars added?", and he said, "Because it 
enforces discipline."

I write tons of code, and then I have to also write unit tests and 
harnesses for it - and I need a new feature that requires even more 
discipline? :)

SC's implementation was like MC's (and ultimately LC's since of course 
MC and LC are the same engine), in which it's truly global and requires 
everything in the environment be compliant with it if it's to be used at 
all.

So while I had no personal interest in explicitVars myself, I used to 
adhere to its requirements because I had no choice if I wanted to share 
code with others who might have it turned on.

Now that RunRev has made this a more optional thing I'll admit I never 
bother with it at all.  I can understand why some do, but I really love 
the freedom of being able to choose for myself whether I use it or not 
for a given script.


>> PS:  Sorry about being over-sensitive about the "trolling" thing. I've
>> known you for enough years that I should have been able to expect
>> nothing more than good humor from you.  I'd just had a complicated
>> morning; thank you for replying so gracefully.
>
> Not a problem on my end. Sorry about the unintentional slight. And
> sorry about your morning - mine was weird as well. Sunspots? UFOs?

In my case it was UFOs:  Uninteresting FUBAR Obstacles. :)

My mood has since elevated with news of some nice fixes in the LC engine 
for Linux (including a particularly difficult one in which Mark 
Waddingham worked around a GTK limitation to provide a workable 
windowBoundingRect, at least for single-monitor setups - thanks Mark!), 
and I very much enjoyed the notice on the Ubuntu.com home page 
announcing their new 12.10 release with the tag line, "Avoid the pain of 
Windows 8" (which they've since replaced with a much less interesting 
tag line, but it made me chuckle while it was up <g>).

Like the Apple "1984", "Lemmings", and "I'm a Mac" ads, and the recent 
ones from Samsung that turn the tables, sometimes a little controversy 
isn't a bad thing; when done well it can even be fun (though I suppose 
Win8 is an easy target given the press it's been getting, not to mention 
Otellini's leaked memo).

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys