regarding this:
"
> 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.
"
i don't know how other languages work, but in python, afaik, it's not possible to access modules that haven't been loaded. there are some that are implicitly loaded, however... i'm not sure if this is what you're getting at? for example: right now, i'm explicitly loading __main__ as an initialization step in csPython (this is done to keep track of it and access it explicitly for various reasons); i suppose other default modules (__builtin__, etc) could be hashed on initialization if that seems desirable for any reason.
for now, i've left it up to the implementation to declare and use something like the LoadedModules hash (that is, i'm not putting it in iScript). i'm using it with LoadModule, in csPython now, obviously. i'm sorta waffling on that, though, because there's no GetModule() or similar in iScript, which means obviously that the user wouldn't have a way of accessing that data from an iScript*. maybe adding GetModule() is the way to go. sound right?
On 3/8/06, Mathew Sutcliffe <[EMAIL PROTECTED]> wrote:
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]?subject=unsubscribe
