Hi,
I worked on the iScript interface and turned it into what it is today,
for the Perl plugin, leaving stub methods in csPython for someone else
to implement, so you have me to blame :)
I also reworked the interface again a year or two ago as part of an
update to the Perl stuff, making a few key improvements, but I haven't
ever committed these changes since I've never found time to thoroughly
test the new Perl stuff. The main changes are: introduction of an
iScriptValue interface for the storage of ints, floats and strings in
the format of the scripting language, meaning we don't need loads of
overloaded Call/Set/Get methods, and the printf-style format strings and
variadic arguments in Call are replaced with a csRefArray<iScriptValue>.
My new interfaces are here:
http://www.crystalspace3d.org/tikiwiki/tiki-index.php?page=ScriptChanges
This may be a separate issue, to a greater or lesser extent, but I
thought it needed mentioning anyway.
I know very little about Python, and I don't understand the relevance of
the code snippets you included, with all the Python API calls in the
main() function, but I'll comment on the rest of what you said.
You make a good point about LoadModule(). This is an area where iScript
currently lacks. Since the Perl 'use' directive (similar to Python
'import' AFAICT) accepts either a path/to/file.pm or Perlish
Module::Name, this is mostly a non-issue for Perl, but I see how it is a
problem with Python. Possible fixes I can see:
1. Add a method to iScript to add paths to PYTHONPATH (for Python) or
@INC (for Perl).
2. Give LoadModule() a different behaviour, as you suggest, perhaps with
a name change to LoadFile(), or perhaps have both methods. If you do it
this way, I prefer for it to take an iFile* instead of a path. Also, you
probably ought still to be able to call LoadModule() in the old style
(ie. with a Pythonic module.name).
It appears to me from what you've said, that it's a Python-specific
detail that if you load a module directly from a file instead of
specifying a Pythonic module.name, all the defintions from the file will
end up in the global namespace. That is clearly not the expected result
from calling LoadModule(), so something must be done to change that, if
you choose option 2 from above.
The fix for this would probably involve introducing a new iScriptModule
interface, like you suggest, unless you can come up with a fix specific
for Python. But we would need to come to an agreement of what the
concept of "module" means to the iScript clique, some homogeneous
definition that will be uniform across all implementations of iScript.
Or to put it another way, we would have to hide any pertinent semantic
differences of say, Python namespaces and Perl packages, from the user
of the interface.
Cheers,
Mat Sutcliffe aka Oktal
-------------------------------------------------------
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]
