Re: executionContexts
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 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: executionContexts
The point here is surely a practical one. RR have built executionContexts into the language for their own purposes, having written the IDE in transcript/revolution (eating their own haggis, as they put it), and presumably they needed it for some aspect of writing an IDE. Assuming that they put it in there with the expectation that they may need to change the way it works, or even what it does, they chose not to include it in the general documented description of the language. We are all free to use it, but RR have no responsibility to ensure that it will work as we expect in future, unlike the documented features of the language, which they must be very careful of changing. We all have bought Revolution, and all versions, AFAIK, 'contain' all sorts of things to which we do not have access, and wouldn't expect to. Best, Mark On 15 Oct 2006, at 09:40, Richmond Mathewson wrote: I do not really understand Dar Scott's "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." I bought 2 varieties of Runtime Revolution and the both contain the 'term' executionContexts now this may be what Dar Scott terms an "intramural" part of RR, HOWEVER: it is part of what I have bought, and as such it would seem that documenting it might not be a bad thing - after all if I stumble across it and use it incorrectly all sorts of unintended results may ensue. Dar Scott's argument seems to imply that I may not open my G4 Mac and poke around inside it because some of the components are "intramural" - sure they are - they are all 'inside the walls', but I don't see what that has to do with it - I own the machine; and, similarly, I own my copies of Dreamcard and RRMedia. Needless to say, this discussion leads us, willy-nilly, towards whether, because I own an instantiation of a programming environment I am allowed to muck around with the source-code. It does seem, however, that if Runtime Revolution (the company) did not want folks like me to access stuff like 'executionContexts' they would have built a 'wall' around it so that it was truly intramural. A secondary point is what Dar Scott means by "underdocumented" - executionContexts seems not to be mentioned at all in the documentation. sincerely, Richmond Mathewson "Philosophical problems are confusions arising owing to the fluidity of meanings users attach to words and phrases." Mathewson, 2006 Send instant messages to your online friends http:// uk.messenger.yahoo.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: executionContexts
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 ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
