executionContexts

[Andre Garzia]

Richmond,

by poking around the IDE source you'll find lots of little gems,  
specially functions and code that can teach you how to do many things  
but having access to the inner bowels of the RunRev IDE does not  
means that this is something you can rely on. The executionContexts  
is one example, there are others. They are a part of the private  
interface of Rev, functions to be used by them, meaning they can and  
probably will change in future releases. It's like you're building  
your code for a customer, a nice little application full of functions  
for it to work and when you deliver to the guy, he disassemble it and  
start asking around why you didn't document that private handler used  
by your own code. You could say to him: "hey, this are inner  
functions of the software, you're not supposed to be here, and in the  
following releases this might change." which is the case of Runtime  
Revolution.

If RunRev IDE was coded in C/C++ then you would have ZERO of this  
undocumented features you talk about, they are not features, they are  
not hidden, they are not undocumented. They are just a side effect of  
coding the IDE in the same language as the one being distributed.  
What you see as new properties to tap and handlers to call are  
nothing but how RunRev team worked to build their own IDE, they are  
not for public comsumption.

Dar Scott was very wise in the words that he didn't bought  
executionContexts. Thats true, the thing he bought (damn, I can't  
spell that word in english) is Runtime Revolution with it's  
Transcript Language, executionContexts is just a side effect of how  
the RunRev team implemented such language and IDE.

To give you an example where I acted like you till I realized what  
was really happening.

I once, in Release 1.1 (I think) was coding a little database app and  
was using the Database Query Builder for it. The DQB appeared to me  
to be very inflexible since the SQL statements were hard coded during  
the development periods till it was revealled to me some functions  
that would allow me to update the SQL statement in a given query. I  
was like in the computer developer equivalent of samadhi or some less  
important bliss state. Such power, hidden!!! I asked for  
documentation too till I realized that the function I was calling was  
an inner function of runtime revolution, it was in fact (In my  
guessing) the actual function used by the Database Query Builder to  
create those SQL statements in the first case. I was not tapping into  
some hidden function to be used by the initiates of the order of the  
sacred xtalk or something, I was actually using the side effect of  
Database Query Builder being done in the same transcript language I  
was coding and leeching on some of its function for my profit and fun.

I came to realize that I was using some function of the RunRev IDE, I  
was only able to use such function due to the message path nature of  
Revolution. Rev having no namespace or protection allows anyone to  
use anything that is put into use. Those things can change as RunRev  
team finds new ways of doing stuff, and again in each release as they  
change their codebase, as long as we're allowed to explore the  
source, we'll keep finding little side-effect-gems but trusting them  
to be present in every release or asking for documentation is not the  
right path here.

I think what we're discussing here is not undocumented functions but  
in fact clever side effects of the message path mixed with having  
access to IDE sources. A much more colorful discussion would be "What  
cool thing did you learned by looking into the IDE sources?" where  
people could say how looking into the IDE scripts they learned things  
and styles of coding that made them a better coder. There are people  
here that are coding xTalk for decades, by looking into their scripts  
a newbie such as me and the others can learn much about proven  
practices that work.


Andre