This looks pretty good to me. I have a few comments and questions inline.
ant elder wrote:
I've spent the weekend getting the script container going again, see the
code in [1], its looking pretty good now. I think we should eventually be
able to use this one container to support all the script language
components
instead of having separate containers for each language.
With a single container, will there still be a way to customize the
support for each language? For example in one language we may want to
map references to instance variables in classes, while in another less
object-oriented language we'll want to map them to global variables.
Another example, one language may support interfaces, while another does
have this concept at all. How will you provide different SCA programming
models to these different scripting languages?
Ideally script
components will be interchangeable between the C++ and Java runtimes, so
with that in mind i've started trying to use the various script
samples from
the C++ runtime, so far thats the Python and Ruby calculator samples, now
copied into the script itests module. Currently there are some changes
required to get these running in the Java runtime and they are:
- Need a java Interface to invoke the sample from a test client
Is it a limitation of the runtime?
Or is it a natural requirement anyway because your test client is
written in Java?
Can you write the test client as a script as well?
- Need to specify the full path of the script file - calculator/ on
script
file resource
- Need to use a .componentType side file
- Ruby script @divideService variable needs to be changed to
$divideService.
Whats the difference between the @ and $ characters in Ruby?
@variable is an instance variable
$variable is a global variable
- Python components use a module attribute to define script file and the
attribute value doesn't include the .py suffix
- Python divide doesn't work with rounding as the line "result =
round(result)" fails as result is a string which seems a bit odd
Requiring the componentType side file seems the main problem, i'm
going to
spend a bit of time now seeing if the java runtime can be made a bit more
dynamic like the C++ runtime to avoid needing these.
You'll probably need to change the Java runtime a little to make
interfaces optional.
...ant
[1]
https://svn.apache.org/repos/asf/incubator/tuscany/branches/sca-java-integration/sca/extensions/script/
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
