Andrew Borley wrote:
On 9/1/06, ant elder <[EMAIL PROTECTED]> wrote:
I've a couple of questions based on I'd like to also have a Python
container
for the Java runtime, and from the perspective of how the the existing
JavaScript and Groovy containers work that we already have for the Java
runtime.
In the implementation.python element do you really need separate path
and
class attributes? This is likely because I don't know anything about
Python
or the C++ runtime work but for comparison a JavaScript impl looks like:
<js:implementation.jsscript="org/apache/tuscany/container/javascript/function/HelloWorld.js"/>
We could probably do that - I was following the style of
implementation.cpp which uses the path attribute to find the .dll,
.componentType and .h files. In the Python case we need to find the
module (.py) and the .componentType file, so internally splitting
relative/path/to/MyModule would probably work, and I guess makes
things slightly simpler for users.
I like this form:
<implementation.py module="PythonModuleName" class="PythonClassName"/>
If I remember correctly, Python developers only reference module names
in their python programs (with "import moduleName") so the path is not
really relevant to them. modules are found on the python search path.
The runtime should configured the python runtime to find modules
packaged with the composite.
For references, could you just use the .componentType side file to
define
references as an alternative to using new annotations? For
JavaScript, if
the .componentType side file defines a reference then the JavaScript
container uses the dynamic nature of the language to automatically
define a
variable with the same name as the reference. I don't have a great
example
but you can see this in the e4x.js testcase where the script uses a
variable
named extHelloWorldService which is the name of the reference
defined from
the .componentType side file:
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/containers/container.javascript/src/test/resources/org/apache/tuscany/container/javascript/function/e4x.js
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/containers/container.javascript/src/test/resources/org/apache/tuscany/container/javascript/function/e4x.componentType
I like this style, but I've got no idea if we could make it work
within Python - I'll have to take a look. That's my favourite of all
the options so far, so thanks!
I like this approach too: a componentType file with the same name as the
python script/module, SCDL reference names map to python variable names,
no need for annotations.
In a second step we may want to look at ways to avoid a componentType
file at all, and allow the python developer to declare SCA references in
his module. I'm not even sure we need to invent annotations, this could
look similar to what you'd do with Ruby meta-programming, you'd simply
put at the top of your python module some executable statements to
declare your SCA references, like this:
Calculator.py
scareference(Calculator.divideService, "divideService")
... or even simpler
scareference(Calculator.divideService)
Class Calculator:
def add(arg1, arg2):
return arg1 + arg2
def div(arg1,arg2) :
return divideService.div(arg1, arg2)
The call to scareference(variable) will be executed when you first load
the python module.
Our implementation of this function can bind the python variable to a
reference of the same name.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
