You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Andrew Borley <aj...@gmail.com> on 2006/07/21 17:29:42 UTC
[C++ SCA] Language bindings & embedding the runtime
Hi,
I've been loosely thinking about what it will take to provide extra language
bindings to Tuscany SCA C++ and how that relates to providing the runtime as
an extension within a language. I've put my early thoughts up on the wiki
here:
http://wiki.apache.org/ws/Tuscany/TuscanyCpp/LanguageBindingsAndRuntimes
I guess with the new spec there will be quite a lot of changes, so this may
all become redundant, but I was just thinking how I'd like to see Python or
Ruby components running alongside C++ ones (and, of course, Java ones too!)
:-)
Cheers
Andy
Re: [C++ SCA] Language bindings & embedding the runtime
Posted by Simon Laws <si...@googlemail.com>.
That's a great idea Pete. I would also like to add that we are just starting
to think about SCA in PHP and is would seem sensible to reuse the work you
have done in C++. So if we could also engineer the C++ implementation so
that it is easy to concume as the basis for another implementation, as well
as supporting different language bindings, that would be splendid.
In particular I'd probably like to be able to take parts of the
implementation because, for example, we may want the model but not all of
the binding framework. So having some clean separation of concerns inside of
the C++ implementation may be useful.
I'm not saying it isn't nicely layed out at the moment of course as I've
only just started looking at the code. On this point I've been making some
notes (attached to the wiki here
http://wiki.apache.org/ws/Tuscany/TuscanyCpp/InsideCppM1) about what I've
been finding out about how the C++ implemenation works currently. Maybe we
could extend this and then hatch a devious plan about how to refactor for
recursive composition, add new language bindings and make it consumable.
Regards
Simon
On 8/2/06, Pete Robbins <ro...@googlemail.com> wrote:
>
> That sounds like an ineresting idea. I'll look into it.
>
> Now that the release is out of the way I want to open up discussion on
> here
> about restructuring the C++ runtime to enable it to support multiple
> language bindings (C++, PHP,...) and also to support the latest Assembly
> Specification for the recursive model. I'm getting some thoughts together
> to
> kick this off.
>
> Cheers,
>
>
> On 02/08/06, ant elder <an...@gmail.com> wrote:
> >
> > How about a C++ JavaScript extension to match the one we have in
> Java/SCA?
> > You can use SpiderMonkey [1] which also has E4X support and then we'd be
> > able to switch SCA JavaScript components btw the Java and C++ runtimes.
> > Using E4X would mean you don't have the databinding issues when using
> web
> > services as the data stays as XML, and you could show us how much faster
> > your C++ runtime is compared to the Java one ;)
> >
> > [1] http://www.mozilla.org/js/spidermonkey/
> >
> > ...ant
> >
> > (sorry a bit late replying but I'm still catching up on mail)
> >
> > On 7/21/06, Andrew Borley <aj...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I've been loosely thinking about what it will take to provide extra
> > > language
> > > bindings to Tuscany SCA C++ and how that relates to providing the
> > runtime
> > > as
> > > an extension within a language. I've put my early thoughts up on the
> > wiki
> > > here:
> > >
> http://wiki.apache.org/ws/Tuscany/TuscanyCpp/LanguageBindingsAndRuntimes
> > >
> > > I guess with the new spec there will be quite a lot of changes, so
> this
> > > may
> > > all become redundant, but I was just thinking how I'd like to see
> Python
> > > or
> > > Ruby components running alongside C++ ones (and, of course, Java ones
> > > too!)
> > > :-)
> > >
> > > Cheers
> > > Andy
> > >
> > >
> >
> >
>
>
> --
> Pete
>
>
Re: [C++ SCA] Language bindings & embedding the runtime
Posted by Pete Robbins <ro...@googlemail.com>.
That sounds like an ineresting idea. I'll look into it.
Now that the release is out of the way I want to open up discussion on here
about restructuring the C++ runtime to enable it to support multiple
language bindings (C++, PHP,...) and also to support the latest Assembly
Specification for the recursive model. I'm getting some thoughts together to
kick this off.
Cheers,
On 02/08/06, ant elder <an...@gmail.com> wrote:
>
> How about a C++ JavaScript extension to match the one we have in Java/SCA?
> You can use SpiderMonkey [1] which also has E4X support and then we'd be
> able to switch SCA JavaScript components btw the Java and C++ runtimes.
> Using E4X would mean you don't have the databinding issues when using web
> services as the data stays as XML, and you could show us how much faster
> your C++ runtime is compared to the Java one ;)
>
> [1] http://www.mozilla.org/js/spidermonkey/
>
> ...ant
>
> (sorry a bit late replying but I'm still catching up on mail)
>
> On 7/21/06, Andrew Borley <aj...@gmail.com> wrote:
> >
> > Hi,
> >
> > I've been loosely thinking about what it will take to provide extra
> > language
> > bindings to Tuscany SCA C++ and how that relates to providing the
> runtime
> > as
> > an extension within a language. I've put my early thoughts up on the
> wiki
> > here:
> > http://wiki.apache.org/ws/Tuscany/TuscanyCpp/LanguageBindingsAndRuntimes
> >
> > I guess with the new spec there will be quite a lot of changes, so this
> > may
> > all become redundant, but I was just thinking how I'd like to see Python
> > or
> > Ruby components running alongside C++ ones (and, of course, Java ones
> > too!)
> > :-)
> >
> > Cheers
> > Andy
> >
> >
>
>
--
Pete
Re: [C++] Javascript implementation type
Posted by Jim Marino <jm...@myromatours.com>.
On Sep 5, 2006, at 2:10 PM, Jean-Sebastien Delfino wrote:
> Jim Marino wrote:
>>> Option 2:
>>> - You don't want to write an SCDL componentType file
>>> - In your JavaScript object constructor you do the following:
>>> function Calculator() {
>>> scaproperty(this.precision)
>>> scareference(this.divideService)
>>> }
>>> - This tells the Tuscany runtime what properties and references
>>> to consider, the runtime initializes them on return from the
>>> constructor.
>> Couldn't the same thing be done by declaring properties/references
>> as constructor parameters, which would be consistent with SCA
>> assembly's use of dependency injection?
>
> Jim,
>
> Both field setting/use of setter methods and constructor based
> injection are consistent with the SCA spec. I am thinking about
> starting with the field/setter based approach first as I'm not sure
> yet how to map (untyped) constructor parameters to references and
> properties.
Of course setter injection is consistent. I was simply saying for
constructors it would be consistent to pass in references and/or
properties as parameters. I would map untyped parameters similar to
what we do in the Java spec: there is an algorithm we added based on
Jeremy's original CDI proposal and if none of the rules apply,
parameters can be properties or references. We updated the Java spec
with the algorithm as part of the July release. Since most ECMAScript
VMs are not strongly typed (except the Actionscript 3 VM), most of
the time I would imagine that the rules will fall through to a
parameter being a reference or property.
There is an interesting Actionscript project that implements an IoC
container. I've used its AOP framework a couple of years ago and it
may be worth looking at:
http://www.as2lib.org/
http://www.simonwacker.com/blog/archives/cat_flash.php
>
>> I think it would also be interesting to support metadata
>> annotations through JavaScript comments (similar to XDoclet) by
>> writing a script parser using regex (or something similar) as in:
>>
>> http://dotnetjunkies.com/WebLog/anoras/archive/2004/08/09/21502.aspx
>>
>
> What I'm proposing here is a simple alternative to annotations for
> now. I did a lot of Javascript development in the past and I
> personally prefer a simple script function to an annotation that
> does not directly translate to executable code, but I'll welcome
> any annotation support as well if people like it, want to volunteer
> and contribute it.
I believe the article had some code that could potentially be used.
> The article you pointed to is from 2004, do you know if the
> approach described in this article became widely used?
>
Macromedia did a massive overhaul of ECMAScript and added a lot of
reflection capabilities into the language (Actionscript 3) as well as
type checking into their VM that would make this much easier. As an
aside it is interesting that Ruby proponents like untyped systems yet
ECMAScript has evolved away from that to more static type checking.
Back to whether it has become widely use, I believe Macromedia was
looking at this at some point. It took Java five versions to get
annotations so maybe SCA could convince the ECMAScript group metadata
is a good thing ;-)
Jim
>> Jim
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Javascript implementation type
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Jim Marino wrote:
>> Option 2:
>> - You don't want to write an SCDL componentType file
>> - In your JavaScript object constructor you do the following:
>> function Calculator() {
>> scaproperty(this.precision)
>> scareference(this.divideService)
>> }
>> - This tells the Tuscany runtime what properties and references to
>> consider, the runtime initializes them on return from the constructor.
> Couldn't the same thing be done by declaring properties/references as
> constructor parameters, which would be consistent with SCA assembly's
> use of dependency injection?
Jim,
Both field setting/use of setter methods and constructor based injection
are consistent with the SCA spec. I am thinking about starting with the
field/setter based approach first as I'm not sure yet how to map
(untyped) constructor parameters to references and properties.
> I think it would also be interesting to support metadata annotations
> through JavaScript comments (similar to XDoclet) by writing a script
> parser using regex (or something similar) as in:
>
> http://dotnetjunkies.com/WebLog/anoras/archive/2004/08/09/21502.aspx
>
What I'm proposing here is a simple alternative to annotations for now.
I did a lot of Javascript development in the past and I personally
prefer a simple script function to an annotation that does not directly
translate to executable code, but I'll welcome any annotation support
as well if people like it, want to volunteer and contribute it. The
article you pointed to is from 2004, do you know if the approach
described in this article became widely used?
> Jim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Javascript implementation type, was Re: [C++ SCA] Language bindings & embedding the runtime
Posted by Jim Marino <jm...@myromatours.com>.
> Option 2:
> - You don't want to write an SCDL componentType file
> - In your JavaScript object constructor you do the following:
> function Calculator() {
> scaproperty(this.precision)
> scareference(this.divideService)
> }
> - This tells the Tuscany runtime what properties and references to
> consider, the runtime initializes them on return from the constructor.
Couldn't the same thing be done by declaring properties/references as
constructor parameters, which would be consistent with SCA assembly's
use of dependency injection? I think it would also be interesting to
support metadata annotations through JavaScript comments (similar to
XDoclet) by writing a script parser using regex (or something
similar) as in:
http://dotnetjunkies.com/WebLog/anoras/archive/2004/08/09/21502.aspx
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Javascript implementation type, was Re: [C++ SCA] Language
bindings & embedding the runtime
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> Supporting OO JavaScript sounds like a good idea to me, and I think I
> also
> prefer the attribute named 'constructor'. Have you thought about how
> properties and references will work with OO? Right now in the Java impl I
> set these in the script global scope, with OO I guess they should be
> set on
> the instance scope.
>
Here's what I propose:
Option 1:
- You write an SCDL componentType file for your Javascript component
- SCDL properties and references are set as fields on your JavaScript
object by the Tuscany runtime (the runtime invokes the constructor and
then sets the fields on the new object)
Option 2:
- You don't want to write an SCDL componentType file
- In your JavaScript object constructor you do the following:
function Calculator() {
scaproperty(this.precision)
scareference(this.divideService)
}
- This tells the Tuscany runtime what properties and references to
consider, the runtime initializes them on return from the constructor.
Another approach would be to say that all properties of a Javascript
object are potential SCA properties and references, and going even
further that you don't even need to declare them ahead of time. In other
words doing this:
<component...>
<implementation.javascript script="Calculator.js"
constructor="Calculator"/>
<property name="currency">EURO</property>
<reference name="stockQuote">StockQuoteService</reference>
</component>
will create the currency and stockQuote fields on your Calculator
object, without requiring you to initialize/declare these fields in your
constructor.
This approach would be more in line with how you develop with JavaScript
IMO, you don't always declare your fields ahead of time...
Thoughts?
> While we're discussing the script language SCDL, one other feature I've
> wondered about is embedding the script source in the scdl instead of a
> seperate file, maybe in a sub-element to the implementation element. For
> short, simple mediation functions that could keep things much more
> concise,
> and readable.
>
> ...ant
I'm less sure about this one. If we did that we'd have to provide good
support for debugging these inline scripts, understand how these scripts
could reference other scripts etc. In general I think Javascript
developers will want to see Javascript and less or no SCDL instead of
having to change their development habits and write Javascript inside
SCDL. I like the "more concise and readable" goal but to me this means
"less SCDL with my Javascript code" instead of "my Javascript code
inside SCDL".
>
> On 9/2/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>> ant elder wrote:
>> > How about a C++ JavaScript extension to match the one we have in
>> > Java/SCA?
>> > You can use SpiderMonkey [1] which also has E4X support and then
>> we'd be
>> > able to switch SCA JavaScript components btw the Java and C++
>> runtimes.
>> > Using E4X would mean you don't have the databinding issues when using
>> web
>> > services as the data stays as XML, and you could show us how much
>> faster
>> > your C++ runtime is compared to the Java one ;)
>> >
>> > [1] http://www.mozilla.org/js/spidermonkey/
>> >
>> > ...ant
>> >
>> > (sorry a bit late replying but I'm still catching up on mail)
>> >
>> Sorry, a bit late replying to this one too :) but we first needed to
>> have a good extension story first. With Pete's and Andy's extension work
>> we now have a good base for looking into implementation and binding
>> extensions.
>>
>> Andy's python extension nicely support OO and non-OO development:
>> <implementation.python module="CalculatorModule" class="Calculator"/>
>> if you want to implement your component with a Python Calculator class.
>> and
>> <implementation.python module="CalculatorModule"/> if you don't like
>> OO programming and don't need a Python class but just want to implement
>> your component with module-level functions.
>>
>> I think this approach will work with Javascript as well.
>>
>> If you want to implement your component with a a Javascript object:
>> <implementation.js script="Calculator.js" prototype="Calculator"/>
>> or
>> <implementation.js script="Calculator.js" constructor="Calculator"/>
>> The "prototype=" form may be more correct w.r.t the Javascript language
>> (which is prototype based instead of class based), but "constructor=" is
>> more intuitive to me. So I think I prefer the "constructor=" form.
>>
>> The Calculator component will be implemented like this:
>> function Calculator() {
>> this.add=add
>> }
>>
>> function add(a1, a2) {
>> return a1+a2;
>> }
>>
>> The runtime will do:
>> o = new Calculator()
>> x= o.add(1,2)
>>
>> Now if don't care about OO and just want functions you just write:
>> <implementation.js script="Calculator.js"/>
>>
>> With this form the JS script will look like this:
>>
>> function add(a1, a2) {
>> return a1+a2;
>> }
>>
>> And the runtime will just do:
>> x= add(1, 2)
>>
>> Thoughts?
>>
>> --
>> Jean-Sebastien
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++] Javascript implementation type, was Re: [C++ SCA] Language bindings & embedding the runtime
Posted by ant elder <an...@gmail.com>.
Supporting OO JavaScript sounds like a good idea to me, and I think I also
prefer the attribute named 'constructor'. Have you thought about how
properties and references will work with OO? Right now in the Java impl I
set these in the script global scope, with OO I guess they should be set on
the instance scope.
While we're discussing the script language SCDL, one other feature I've
wondered about is embedding the script source in the scdl instead of a
seperate file, maybe in a sub-element to the implementation element. For
short, simple mediation functions that could keep things much more concise,
and readable.
...ant
On 9/2/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> ant elder wrote:
> > How about a C++ JavaScript extension to match the one we have in
> > Java/SCA?
> > You can use SpiderMonkey [1] which also has E4X support and then we'd be
> > able to switch SCA JavaScript components btw the Java and C++ runtimes.
> > Using E4X would mean you don't have the databinding issues when using
> web
> > services as the data stays as XML, and you could show us how much faster
> > your C++ runtime is compared to the Java one ;)
> >
> > [1] http://www.mozilla.org/js/spidermonkey/
> >
> > ...ant
> >
> > (sorry a bit late replying but I'm still catching up on mail)
> >
> Sorry, a bit late replying to this one too :) but we first needed to
> have a good extension story first. With Pete's and Andy's extension work
> we now have a good base for looking into implementation and binding
> extensions.
>
> Andy's python extension nicely support OO and non-OO development:
> <implementation.python module="CalculatorModule" class="Calculator"/>
> if you want to implement your component with a Python Calculator class.
> and
> <implementation.python module="CalculatorModule"/> if you don't like
> OO programming and don't need a Python class but just want to implement
> your component with module-level functions.
>
> I think this approach will work with Javascript as well.
>
> If you want to implement your component with a a Javascript object:
> <implementation.js script="Calculator.js" prototype="Calculator"/>
> or
> <implementation.js script="Calculator.js" constructor="Calculator"/>
> The "prototype=" form may be more correct w.r.t the Javascript language
> (which is prototype based instead of class based), but "constructor=" is
> more intuitive to me. So I think I prefer the "constructor=" form.
>
> The Calculator component will be implemented like this:
> function Calculator() {
> this.add=add
> }
>
> function add(a1, a2) {
> return a1+a2;
> }
>
> The runtime will do:
> o = new Calculator()
> x= o.add(1,2)
>
> Now if don't care about OO and just want functions you just write:
> <implementation.js script="Calculator.js"/>
>
> With this form the JS script will look like this:
>
> function add(a1, a2) {
> return a1+a2;
> }
>
> And the runtime will just do:
> x= add(1, 2)
>
> Thoughts?
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
[C++] Javascript implementation type, was Re: [C++ SCA] Language
bindings & embedding the runtime
Posted by Jean-Sebastien Delfino <js...@apache.org>.
ant elder wrote:
> How about a C++ JavaScript extension to match the one we have in
> Java/SCA?
> You can use SpiderMonkey [1] which also has E4X support and then we'd be
> able to switch SCA JavaScript components btw the Java and C++ runtimes.
> Using E4X would mean you don't have the databinding issues when using web
> services as the data stays as XML, and you could show us how much faster
> your C++ runtime is compared to the Java one ;)
>
> [1] http://www.mozilla.org/js/spidermonkey/
>
> ...ant
>
> (sorry a bit late replying but I'm still catching up on mail)
>
Sorry, a bit late replying to this one too :) but we first needed to
have a good extension story first. With Pete's and Andy's extension work
we now have a good base for looking into implementation and binding
extensions.
Andy's python extension nicely support OO and non-OO development:
<implementation.python module="CalculatorModule" class="Calculator"/>
if you want to implement your component with a Python Calculator class.
and
<implementation.python module="CalculatorModule"/> if you don't like
OO programming and don't need a Python class but just want to implement
your component with module-level functions.
I think this approach will work with Javascript as well.
If you want to implement your component with a a Javascript object:
<implementation.js script="Calculator.js" prototype="Calculator"/>
or
<implementation.js script="Calculator.js" constructor="Calculator"/>
The "prototype=" form may be more correct w.r.t the Javascript language
(which is prototype based instead of class based), but "constructor=" is
more intuitive to me. So I think I prefer the "constructor=" form.
The Calculator component will be implemented like this:
function Calculator() {
this.add=add
}
function add(a1, a2) {
return a1+a2;
}
The runtime will do:
o = new Calculator()
x= o.add(1,2)
Now if don't care about OO and just want functions you just write:
<implementation.js script="Calculator.js"/>
With this form the JS script will look like this:
function add(a1, a2) {
return a1+a2;
}
And the runtime will just do:
x= add(1, 2)
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [C++ SCA] Language bindings & embedding the runtime
Posted by ant elder <an...@gmail.com>.
How about a C++ JavaScript extension to match the one we have in Java/SCA?
You can use SpiderMonkey [1] which also has E4X support and then we'd be
able to switch SCA JavaScript components btw the Java and C++ runtimes.
Using E4X would mean you don't have the databinding issues when using web
services as the data stays as XML, and you could show us how much faster
your C++ runtime is compared to the Java one ;)
[1] http://www.mozilla.org/js/spidermonkey/
...ant
(sorry a bit late replying but I'm still catching up on mail)
On 7/21/06, Andrew Borley <aj...@gmail.com> wrote:
>
> Hi,
>
> I've been loosely thinking about what it will take to provide extra
> language
> bindings to Tuscany SCA C++ and how that relates to providing the runtime
> as
> an extension within a language. I've put my early thoughts up on the wiki
> here:
> http://wiki.apache.org/ws/Tuscany/TuscanyCpp/LanguageBindingsAndRuntimes
>
> I guess with the new spec there will be quite a lot of changes, so this
> may
> all become redundant, but I was just thinking how I'd like to see Python
> or
> Ruby components running alongside C++ ones (and, of course, Java ones
> too!)
> :-)
>
> Cheers
> Andy
>
>