Chris Case wrote:
Personally, although I don't have enough knowledge to talk in a
technical manner on most of this, I think that there should be the
option to specify a VFS path when you load a module. Make it so that
you could do:
iscript->LoadModuleObject("/gamedata/modules/amir.foofunc")
or
iscript->LoadModuleObject("amir.foofunc")
Whether you use a VFS path or an iFile pointer is a question of taste,
but I think if you have methods to load modules from VFS/iFile and from
a canonical module name, then they should be separate methods. We can't
be sure that all scripting languages will treat a file and a module as
equivalent, for instance some might have modules made of multiple files,
or files containing multiple modules. So to avoid confusion about the
behaviour of the method, and to limit the exposure of implementation
details in the interface, it should be split into two methods with more
strictly-defined behaviours. For example:
csRef<iScriptModule> LoadModule(const char*);
//---
bool LoadModuleFile(iFile *);
iScriptModule* FindModule(const char*);
Of course, you don't need to change the name to LoadModuleFile if you
use an iFile pointer because the method overloading will allow them to
be separate methods anyway. And that's another issue for personal
preference to decide.
Also, I don't think FindModule() should be limited to getting modules
that have been loaded through the iScript interface. There may be
standard modules that are always available, or other circumstances in
which you may want access to a module you haven't explicitly loaded
yourself, and you should be able to get an iScriptModule* for those.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]
