Sorry your browser is not supported!

Many may be aware that subroutines can be written inside of functions and be local to that function. If you didn't know, well, now you know. I had done this but I hadn't really taken advantage of it much until recently. The usefulness of this is far reaching as I see it.

It is possible to create an entire working application all contained in a single function. You can then #INCLUDE this function or plop it directly in the source of another application. To me, this means having a plugin system.

For example, let's say you have a matrix editor. You've got it working great to create, modify, texture, etc. any matrix you want. But you started thinking, it would be great to expand this into a full level editor. Instead of trying to rework the code in your matrix editor, you could create a function with it's own set of local variables and subroutines that runs completely in and by itself that manages objects. Once the function is done, you call it from the main code of the matrix editor, and your object manager will do it's thing. When you are done, you can release control back to the matrix editor.

This usage may seem obvious, but until you create an entire working application that's contained in a function, you may not realize how useful it can be. The thing is to, the variables are local to the function. You don't have to work on the main app and the plugin at the same time to make sure they work together if you don't want to. And, if you use local arrays as the variables in your function, you can undim all of them so there's no memory overhead when you exit the function.

The use of local subroutines is really what makes this nice. You can use local variables with the local subroutines as if they were functions themselves. It takes a little getting used to and uses a slightly different method than passing values as parameters to standard functions. You can of course use other functions within functions, you just can't write them as included inside a parent function - that's why I like the use of subroutines. A single function can be used for an entire application.

So instead of thinking of functions as just value calculators, or bits of code to perform a task or save a file, think of them as potential complete applications that can be shared and run concurrently in one common source.

I think this is the first musing thread we've had
This could prove very useful, especially for team projects.

That sounds really interesting - would this mean it would also work across languages? Or would you have to stick with the same language.

I'm speaking specifically of DBC. I don't know if DBPro function variables are static. DBC function variables are; they will hold the same value even if you exit the function.

For lnaguages like C, you have the ability to use things like DLLs that can be completely self contained applications if you will.

For DBC, this could be a "plugin" system for source code. This wouldn't work after the source is compiled into an exe.

That is kinda how c++ works, your program is contained in one function and ran from there like main() or WinMain() or DarkGDK() depending on the type of program(like WinMain() is used when handling windows stuff, and DarkGDK() is used for, well, dark GDK stuff)

Nah, this is one of those DBC to Dbpro gotchas.