To Include, or not Include

Singularity · Fri Jan 11, 2008 3:28 pm

Lone, when I said append... I meant that's where I tend to put all of my includes (at the bottom) and just said "append" because that's what I'm used to. It probably includes at the include statement.

Quote:

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

LOL, a little bit of structure can fix a lot of that. As EP said, if you put something like....

Code:

# -----------------
# I should never get here!
halt
# -----------------

At the top/bottom of your include, it does stop that. Also better macros can really prevent the accidental warp offs in most cases, along with good indents to help you catch where a return should be... :-)

The reason I use includes is extensibility. Copy-paste works, but what if you figure out a better way to do something? Or... ick, a serious bug? Going thru each script that uses your code and fixing it is a real pain in the butt. This way I can make a single fix and fix them all.

Quote:

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.

*nod* Includes are included during the compilation run, not during execution. Makes sense to me.

For those that are cross-eyed...

A .TS file is a text file. TWXproxy can't understand text by itself, so it first makes a call to the compiler where the .TS file is made into a kind of processed bytecode. That bytecode is then read by TWXproxy. Includes are handled in the first run, along with some syntax checking and a few other things. But the actual code itself is handled during execution.

Quote:

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.

The problem then becomes trigger execution. Because triggers are gotos, and not gosubs, you can't control them so neatly. Sometimes I need triggers that sit around in the background and if they execute I need it to pass back to the main block-level so it can finish handling (ie: kill any other active triggers, then do something important).

One such example would be an adj torper. If someone hits a fig outside of the zone, it probably needs to reset the trigger (can be done internally to the include) but what if I don't want it to just reset and keep sitting? What if I want the same include to be able to shut itself off and turn on a pwarp torper? Ie: include-level triggers that need to be able to do things at the main-level code?

That's where callback handlers come into play. They get used in lower-level languages all the time, the windows API is full of them.

It's basically:
MyRoutine(var1ptr, var2ptr, callbackptr)

When the command runs, it grabs the vars from the 2 ptrs, then will callback when it's done. A very common example is error handling, you can setup an error handling callback to case out the problem and terminate or reset as needed.

If you can find a way to do that w/ triggers without resorting to this, by all means do tell. =)

To Include, or not Include

Who is online