with doing it this way, though, i'm not 100% sure if this makes sense with how other scripting languages work. if someone can tell me what to do here, i'd appreciate it: the problem is that i don't know if an iScriptObject will always be appropriate to point to and use modules in any given scripting language. i assume other languages would have to make their own (csFooModule : public iScriptObject) classes... then LoadModule implementations would be expected to update the csHash representing loaded modules... i just worry about the possibility that this would mean conceptualizing modules as objects in languages where it's inappropriate. maybe at this level, it doesn't matter, though. i think i prefer using iScriptObject over iScript -- no RunText(), etc. input would be appreciated, though.
now that i'm on the subject, there are some other things on a basic design consistency level that i've been a bit shaky on, because i've never done this before. is it a bad idea to define
csHash<csRef<iScriptObject>, csRef<iString> > LoadedModules;
in iScript? it leaves me with an uneasy feeling, which generally makes me think i'm doing something wrong in doing that. should it be up to the implementation to do this if the functionality is desired? feels like a stupid question to ask, now that i think about it...
and one more question. i like the changes proposed here (as pointed to before): http://crystalspace3d.org/tikiwiki/tiki-index.php?page=ScriptChanges
and am also working on implementing those for csPython. but i wonder if definitions like:
virtual csRef<iScriptValue> Call (const char *name, const csRefArray<iScriptValue> &args = csRefArray<iScriptValue> ()) = 0;
are ok? they seem to require script.h to include csutil/refarr.h -- another thing that makes me feel uneasy because it feels like it's going against some design rule.
in any case, i guess i ought to say that i'm working on these things now in the hope of improving csPython generally. right now it's not really possible (easy) to pass values back and forth between python and c++ in cs, and i hope to change that. input on any of the above would be appreciated.
On 3/8/06, Jorrit Tyberghein <[EMAIL PROTECTED]> wrote:
Sorry for jumping into this discussion a bit late but I'm strongly
against yet another interface (iScriptModule). Why not simply extend
the existing iScript? That way there is no need for a new python
plugin either (which I strongly dislike).
Greetings,
On 2/15/06, Amir Taaki <[EMAIL PROTECTED]> wrote:
> so are we agreed on this then? -
>
> - new iScriptModule object, supporting overloaded Call
> - internal hash of iScriptModule objects in iScript, which can be looked up
> using FindLoadedModule(const char*)
> - Do we break the current LoadModule for python? (as far as I'm aware the
> RunText should still work, because loading the modules should include them
> in global interpreter - TODO: check this out). If it does break behaviour,
> should I precede or make a new LoadModuleObject or something
> - AddModuleLoadingPath function to update PYTHONPATH variable (takes a
> const char of a VFS path which is internally translated to absolute path)
>
> Alternatively we could do away with the iScriptModule object, and store the
> raw python module objects (merely adding an extra modulename argument to
> iScript::Call)
>
> Just thought I'd make some pointers in case we followed the 'alternative'
> method...
>
> - no new iScriptModule object
> - Same Call functions, but function names must have unique identifiers
> since they all exist in global scope
> - LoadModule stays, but also get LoadScriptFile function
> - no need for AddModuleLoadingPath since LoadScriptFile takes a path to
> python script
>
> Amir Taaki
>
--
Project Manager of Crystal Space (http://www.crystalspace3d.org)
and CEL (http://cel.crystalspace3d.org )
Support Crystal Space. Donate at
https://sourceforge.net/donate/index.php?group_id=649
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]?subjectunsubscribe
