Re: [Crystal-develop] about iScript interface

[Mathew S. <ok...@gm...>]

From: Pablo Martin <ca...@si...>
> 
> i hope all is well and see you soon in irc!!

Hi Pablo, I'm very well thankyou, hope you are. I was delighted to see the tracker post informing that you'd implemented the new iScript for Python.

I stayed at genjix's house last weekend and we sorted out design for the new skeletal animation system. I've also figured out how to fix the segfault in perlsimp.pl, and will post to the list about that tomorrow. It seems like buggy Swig re template inheritance in csString.

I'm still working on getting Internet back at home, so emailing from work. I hope to sort this out soon so I can get back on IRC.

> 1- How can iScript create an iScriptValue/Object from a cs pointer?
> There doesnt seem to be a way of doing it, and it is needed for example
> for setting object_reg pointer inside the cspace module.

I agree this would be a useful function, but any approach we take will be ugly to some degree (e.g. void pointer). I previously approached this problem with the iScriptObject::SetPointer() method, but that requires first creating an object in script or with iScript::New() and then overwriting its pointer, very error-prone.

Setting object_reg can simply be done internally by the iScript implementation when loading the cspace module, though; no need to expose a public method if that is all it is needed for.

> I added an internal RValue(const char*tag, void *ptr) to cspython to be
> able to do this, but i guess apps will also want to do it. I propose
> adding something like this to the api.

This seems to be the least worst way. TODO...

> i checked how perl does this, and casting to an int is both ugly and
> problematic (doesnt compile in 64bit for example).

I can change the Perl implementation to do this with the SWIG_ calls instead of casting to int, but I wanted to avoid linking with the Swig runtime.

> 2- Why do RValue return csPtr<iScriptValue>, but then Store and similar
> functions use "iScriptValue *"? Makes it a bit annoying to use...

The accepted wisdom was that csPtr<> should be returned by methods that create a new object and don't retain a reference to it. No reason why these shouldn't be changed to return csRef<>s though, as that would make it a bit less convoluted for users, and that could probably be done without breaking backwards compatibility.

> 3- About the parts of api which accept names from "cspace module or
> not", do you think this is really necessary? It makes implementation a
> bit more convoluted.

It makes the interface less implementation-specific, since if the user wants to specify "csVector3" for instance, they would have to make the distinction between "cspace.csVector3" for Python and "cspace::csVector3" for Perl etc. Implementation complexity is preferable to interface complexity/non-generality :) On the other hand, we could for instance adopt the Python syntax universally and have the Perl implementation replace "." with "::".

Many thanks,
Mat
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer