Wondering how Includes work.

If the Main.ts file Includes a STATS.ts, and a LIB.ts; I realize that the LIB.ts cannot directly access the $STATS~Vars unless the Main.ts passes the info (ie: setVar $LIB~var $STATS~var). My question is, if the LIB.ts also includes the same STATS.ts (same file, same directory path), does TWXC actually include STATS.ts twice?

I started using Includes as a better way to manage larger projects, but at the same time want to be as efficient as I now how to be.

Thanks in advance

In TWX proxy it's all compiled into a single file. Variables and routines are prefixed w/ the include name, but basically it's just attached to the bottom of the file. I believe you can access another include's data just fine, have you actually tried it?

Is the compiler smart enough to not include the same include twice... or would it mess something up? I don't know. You'll probably need to ask EP for that answer.

Tried again with a simpler file. seems to work now.. laff

Looking back I think I was trying to access variables in included files that wernt initalized (sub procedures hadn't been called), which makes sense.

Thanks

Hmm, this is something I was confused about too. I didn't realize that including it once would allow all the pieces to call from the included subroutines. Good stuff.

MD

Little trivia...
goto :~blah

Calls to :blah in the main file. So you can create callback handlers for included triggers... which ends up being pretty useful as you expand your include usage.

Wow. That is really kewl

For the longest time I didnt use them and I would just have routines I use all the time stored somewhere then copy and paste it in.
Now I just pop in the include and it is there.

Includes are pretty cool but if you forget the return and other parts, you will be sent flying into space lol.

I use to do Same. Cut & Paste, and repeat. But I'm tired of hunting around hundreds of line of code.. leaving XXX's as bookmarks to Ctrl-F back to. Laff. Besides. a nifty feature of Includes is when debugging, TWX tell you which Line AND which Include the Error occured (Esp handy for those those pesky errors where a 'End' is missing.

Same thing over and over..includes are much handier than cut and paste.

Comms checks/prompt checks/saftey routines...etc etc.

The only downside to includes I have seen at all is when you have a very large script (10000 lines or more - obviously doesn't happen often) that uses includes for a commonly called subroutine. I have seen a performance hit if subroutines are located at the bottom of a long script, and since includes essentially append them to the end this can cause a problem. One such subroutine that was causing a big speed drop with the bot was quikstats.

Not a problem most people would have though, since most scripts don't run long enough to make it matter. Includes certainly make updating your routines within all your scripts much more efficient, plus all the other benefits already stated.

MD

Not sure about that. I have include statements at the top and bottom of my scripts. Seems that if you put a include at the top, you need to use a 'goto' to skip over it.


One idea I'm toying with is making use of the processin command. Having a Daemon type script running that waits for a call (via proprietary Tirggers), then signals back via a similar process. Like having customized Interrupts.

Heh, here's my quote of MD:
"Some users experienced a performance hit when using my 25,000 line bot, but it's much better now that its only 12,000 lines."

I think the basics have been covered. I would discourage calls from an include to the calling script or to another include of the calling script though. If you find yourself doing that, there's likely a better technique you should use. Best practice would be setting an include's variables from the main routine, and calling subroutines that return. You might setup a $subroutine~result type variable that can be queried from the main script rather than letting an include set some variable in the main script. I can expand upon that if needed.

+EP+

Oh good.. Well dang I guess I will break down and start putting my stuff into includes again. Thanks Lone.



11,800 thanks very much.
Heh


MD

I realize that this can be confusing, so let me attempt to clarify. Includes aren't executed... they're included. When you include a file, you aren't actually launching it. Includes can and probably should be listed at the top of the main script, for clarity. When you execute a script, TWX scans right away to see if any includes are specified. If there are, then it tokenizes the include's variables and :headers, essentially prepending "IncludeScriptName~" to these values. The very first line of that include could be HALT (and probably should be if it isn't intended for stand-alone use), and it will work fine.

I developed a habit of writing scripts for use as stand-alone scripts, or as includes. I would group a list of common routines together in a file for use as an include, then create a simple menu or prompt at the beginning (in case it's launched stand-alone) to allow access to any routines that are useful if called directly. The most important part though, is the documentation at the beginning of a script or include, defining it's calling conventions.

+EP+

Okay. Does TWX include or 'stick-in' an Include more or less where you put the Include statment in the Main file?

To be a tad clearer: If I include STATS.ts at the top of the main file with code beneath, does TWX insert the STATS.ts at the very begining of the CTS, or as Sing indicated; TWX appends all includes at the end of the main TS ?