Split Script Class

[Nutster]

I know it would be a bit of work, but I can see some advantages of splitting the Script class into 2 classes, one to read, store and tokenise the script and a second class to actually execute the script.

The Execute class would contain all the information about which line is running, intermediate values. All built-in functions would be members of the execute class.

The new Script class would only contain instructions regarding the script itself and giving the token stream for a given line or the actual text. All the parts for actually running the script would be in the Execute class. All the #... commands would be managed by the Script class alone. The Execute class never sees them.

The application would tell a script object to load the script and then upon successful completion of that, the app would create an Execute object (on the heap) and tell it to start running the script.

By storing the Execute object on a stack, the UDF call could just go to (:scared:) the line at the start of the function and when it returns, pop the execute class, put in the return value and then resume the line as it was. The C++ stack would no longer be needed! We could could get rid of the UDF recursion limit.

How does this sound to others?

[Bartokv]

Sounds like a good idea... But to be honest, I'm having a little difficulty understaning how this could be accomplished for a complied script (without significan bloat).

[Jon]

Sounds like a good idea... But to be honest, I'm having a little difficulty understaning how this could be accomplished for a complied script (without significan bloat).

It's internal stuff. It wouldn't make any difference to anything else.

[Bartokv]

My bad.. Sorry for being an idiot.