RE: Re: Netscape 'Spidermonkey' JavaScript bi ndings

> I agree. It is better to use static member data to store the function
pointer
> locally. 

To my (current) knowledge this isn't how boost::python currently works is it
though - so would this cause a problem if we went down this route currently?


> The main problem will be generic type conversion. This is probably the
first
> thing that should be generalized between differen language binders.

I imagine this will start off as something simple of the form:

template<class ScriptContext, class ScriptObject>
struct type_conversion
{
	template<class Type> ScriptObject* convert_from(ScriptContext*,
Type);
	template<class Type> Type convert_to(ScriptContext*, ScriptObject*);
};

and the implementer just provides specialisations for each supported atomic
type.  Then for the general case it can create a default wrapper for the
object or auto'magic'ally pick up a user defined wrapper if it has been
defined already - I imagine something like this exists already in
boost::python (Yeh I know I still have to dig into it more ;) ).  I also
need to read up on the different forms of managment of parameters in
boost::python (lots of reading for me!).

Also as we would be providing a consistent interface through langbind for
the C++ client code would it also make sense to create an uniform interface
for operating the interpreters? (Evaluating scripts and so forth)  I imagine
we'd want to concentrate on just basic functionality for this.  This would
allow the client C++ code to be totally script language agnostic - was this
planned anyway?

Warrick


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click