Neutral Robot Boy wrote:
PyObject* -- a generic
class for all python data including functions, modules, and all other
data types (lists, dictionaries, floats, you name it). so, in the case
of python, an implementation of iScriptObject seems in order.
An iScriptObject is supposed to represent an object in the OO sense. I
don't know Python, maybe everything is an object. Regardless, it seems
okay to allow specific iScript implementations to expose iScriptObject's
that represent other concepts in the scripting language. Perhaps this
could be extended to other plugins, for instance iScriptObject's that
represent Perl arrays, hashes, etc. But using them would be less
portable than, say, Call() calls to script functions exposing the
functionality of the array/hash/whatever. Also, how could you
distinguish objects from arrays/hashes/etc in Perl without using the
$/@/% operators to refer to them, thereby introducing a
language-specific detail into the interface?
Specifically talking about modules as iScriptObject's, I think you were
right when you suggested other languages might not represent modules as
objects; we can't assume that. But we could artifically build into all
the plugins separate iScriptObject implementations for modules, since
the methods for iScriptObject and a hypothetical iScriptModule would
seem to be very similar. Explicitly "overloading" an interface like that
is "evil," but _might_ be appropriate sometimes. I'll leave it to
someone else to decide, but I'm "mildly against."
The alternatives are, as Jorrit said, to add methods to iScript that
take an extra const char *module argument, or to add an iScriptModule
interface, which would seem to add bloat to the iScript clique. One
other alternative is a shortcut, to just allow the languge-specific
fully qualified names of identifiers to be used to access things, for
instance Python foo.bar or Perl foo::bar. I just present the options, I
don't want to make a decision; I'll leave that to someone else :) But I
think a decision should be made. I'm optimistic about the potential of
the scripting support in CS to be a major growth area in the
not-too-distant future; as well as conventional scripting in games with
Python/Perl/Java I'm interested in the prospect of supporting SWIG
targets like O'Caml and other functional languages for the application
of specialist AI.
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...
I don't see a reason not to, but as I said before, it would also be
useful to allow accessing modules (that haven't necessarily been loaded
by the user) through the scripting language API.
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.
I don't think there's a design rule that says headers can't include
refarr.h, unless anyone wants to correct me. The alternative is just to
get rid of those default values, which wouldn't be too bad I guess. Once
again, "someone else" can decide. This raises the question, should the
const char *module argument (the alternative to iScriptModule) have a
default value that represents the "global namespace"/"main module"/etc?
If not, would we have separate methods for accessing globals (the
current methods) and module members (new methods) and would that imply
an equivalent "bloat hit" as with the iScriptModule option?
I'm pleased you're implementing my proposal for an updated iScript and
friends. You may want to check with what Amir is doing so you don't
duplicate work.
Amir Taaki wrote:
so are we agreed on this then? -
Sounds good :)
-------------------------------------------------------
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?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]
