People have been asking for a way to create code libraries in Liberty BASIC for some time. I have thinking about how to do this using an in-memory model. Over the weekend Scott and I worked on adding some modularity to the Run/Liberty BASIC language. Here's how it works so far. We are open to suggestions.
The RUN statement has a new form. If I want to use mymodule.bas as a module in a program I am writing I would code it like this:
run "mymodule.bas", #myModule
This causes mymodule.bas to be compiled into memory. It will execute code up to the first wait statement. This is how values will be initialized. The program then becomes an object assigned to the #myModule handle.
Then you can call any function on that program from within the calling program, like so:
#myModule myFunction(myParameter)
or even use the invokation in a more complex expression:
print "digits: "; len(#myModule myFunction(myParameter))
You may recognize this syntax as being the same as for controlling widgets. It relies on the same underlying mechanisms to do its work.
When we're done with this, modular programs loaded this way will be cached in memory and will only recompile when the source file changes.
Subscribe to:
Post Comments (Atom)
4 comments:
Hate to seem to always be whining... but are we supposed to distribute the modules in source form?
Hey Bill,
Of course you won't need to distribute the source code. ;-)
Ooh, ooh! I like it! Modular programming in LB. I realize I err on the OOP side of things, but this allows me to organize things in a more OOP manner. For instance, I could create code that does nothing but interact with the database and put it in a module. This module could be used by several projects. I like breaking my project done into smaller tasks. Cool!
Based on Carl's reply to the first comment, I assume the following statement would also work:
run "mymodule.tkn", #myModule
This would allow the use of a compiled (possibly third-party) module.
Post a Comment