pococapsule or (lua) scripting?

[Rick]

Hi,
for a recent project we used PocoCapsule to configure our application.
This worked fine.
Later in the project we integrated lua (embedded scripting) in the
application in order to interact with the application from a scripting
environment.
We then realized that also the configuration (instantiating and wiring
of objects) could be done with a lua-script. This turned out to work
fine. So at this moment we also do the configuration with a lua-
script.
Instead of using a pococapsule container with an xml configuration
document we now use a lua-script.
This works "as well as it did with with pococapsule".

So now we are considering to remove pococapsule from the project and
to configure the application with lua.

Before doing that, i am thinking what possible advantages pococapsule
has in comparison with the (lua)scripting approach.

And more in general, how does the approach as used by PocoCapsule and
others like Spring for Java compare to a scripting approach?

regards,
Rick

[Ke Jin]

There are many differences between XML code of IoC containers and
scripts code of Lua/Java script languages, such as:

- declarative vs imperative (a.k.a procedural)
- describe "what" vs express "how"
- to explicitly visualize the requirements/results vs to verbalize
procedures that produce the implicit results.
- statically verifiable schema and free from runtime debug vs static
grammar/type check and encourage runtime debug
- code is manipulable as first class object (i.e. code is data) vs
code is intangible/protected from user code.
- code is neutral to programming language (i.e. can be manipulated by
user code in any other languages) vs code is languages/environments
specific.
- ubiquitous code transformation/query support (e.g. declarative XSLT
and XQuery) vs code transformation and query are not the culture.

Regards,
Ke

[Ke Jin]

Rick,

Besides, many application configurations involve object wiring and
complex data types as C++ function call input parameters and returns.
With PocoCapsule, the configure files themselves serve as interface
definitions to generate C++ calling proxies which make this a trivial
and transparent issue to users. For Lua C++ binding frameworks tend to
require user to write/maintain additional interface definitions (a.k.a
binding modules) or write proxies by hand that could be a challenge if
the C++ function call involve non-primitive parameters/returns.

Regards,
Ke

On Jun 18, 1:36 am, Rick <rick.van.haa...@gmail.com> wrote:

[Rick]

Hi Ken,

thanks for the response!

First of all I want to say that i'm not into a "one is better than the
other" mode or something like that.
We used pococapsule and are happy with it. It is that we now have to
decide if we use pococapsule for the
application setup and wiring, or use a lua script for this, given the
fact that we are using lua anyway for scripting purpose.
I added comments on your reply, it would be nice if you could give a
reaction on those comments.

>>- declarative vs imperative (a.k.a procedural)
>>- describe "what" vs express "how"

Although lua (or any other scripting language) has an imperative
nature, the "configuration" script also just spefies what to do:

object1 = createClassA()
object1 = createClassB()
connect(object1, object2)
object1.go()

Lua is here just a wrapper around the classes and static methods.
So in certain sense it is as declarative as the pococapsule
configuration is.

>>- to explicitly visualize the requirements/results vs to verbalize
procedures that produce the implicit results.

A pococapsule configuration is explicit in its types, a script indeed
not, so pc has it's advantages here.

>>- statically verifiable schema and free from runtime debug vs static
grammar/type check and encourage runtime debug

Very strong point of pococapsule, wrong configuration in lua-script
cannot be determined staticaly, as such a wrong configuration could
cause damage,
even very late during runtime.

>>- code is manipulable as first class object (i.e. code is data) vs
code is intangible/protected from user code.

Doesn't that also appy to the scripting code/data?

>>- code is neutral to programming language (i.e. can be manipulated by
user code in any other languages) vs code is languages/
environments
specific.

What is here the real advantage? is it that xml support is common to
many environments?
Then you maybe have a point, otherwise i would say "any language can
create a script, it is
just text", this script can be executed by the runtime environment"
without any extra (compilation) step.

>>- ubiquitous code transformation/query support (e.g. declarative XSLT
and XQuery) vs code transformation and query are not the
culture.

The transformations to DSL's is a strong point of pococapsule (if that
is what you mean with this)


regards,
Rick

[Ke Jin]

Rick,

Thanks for your valuable input and questions. See inline responses.

Regards,
Ke

On Jun 19, 5:12 am, Rick <rick.van.haa...@gmail.com> wrote:
> Hi Ken,
>
> thanks for the response!
>
> First of all I want to say that i'm not into a "one is better than the
> other" mode or something like that.
> We used pococapsule and are happy with it. It is that we now have to
> decide if we use pococapsule for the
> application setup and wiring, or use a lua script for this, given the
> fact that we are using lua anyway for scripting purpose.

There is no golden hammer solution, and not everything is a nail.
Specifically, not everything expressed in texts are scripts. A script
means a procedural program to be executed interpretively statement
after statement (we will see examples in further discussions below).
XML documents in PocoCapsule (or in IoC containers in general), on the
other hand, do not describe such operation flows. This difference is
just like assembly instruction book of a vehicle vs its design
blueprint. They serve for different purposes and use completely
different ways (languages or symbols) to present their contents. In my
opinion, the biggest misreading on IoC containers is seeing these XML
documents as scripts.

> I added comments on your reply, it would be nice if you could give a
> reaction on those comments.
>
> >>- declarative vs imperative (a.k.a procedural)
> >>- describe "what" vs express "how"
>
> Although lua (or any other scripting language) has an imperative
> nature, the "configuration" script also just spefies what to do:
>
> object1 = createClassA()
> object1 = createClassB()
> connect(object1, object2)
> object1.go()
>
> Lua is here just a wrapper around the classes and static methods.
> So in certain sense it is as declarative as the pococapsule
> configuration is.
>

This Lua program is _not_ declarative but procedural. The code has to
have the createClassA() and createClassB() placed before the connect
(a, b). The following code that merely changes the order:

connect(object1, object2);
object1 = createClassA();
object2 = createClassB();

wouldn't work in Lua. Generally speaking, in procedural languages,
programmers have to explicitly program the operations orders of
operation control flows (just like a vehicle assembly instruction book
has to specify the assembling work orders and control conditions).
Besides, the two mutable variables object1 and object2 refer to the
result of the createClassA() and createClassB() invocations.

On the contrary, for a real declarative program, the order of
statements does not imply the order of the underlying operation order
or control flow. For instance, the following code in PocoCapsule:

<bean class="void" factory-method="connect">
<method-arg ref="object1"/>
<method-arg ref="object2"/>
</bean>

<bean id="object1" class="A" factory-method="createClassA"/>
<bean id="object2" class="B" factory-method="createClassB"/>

is is idential to the code that has the different node orders. Also,
the id "object1" and "object2" are not mutable variables that refer to
function calling result. Instead, they denote the the function calls
(that create the beans) .

Because the wiring program of this Lua example follows an user
designed procedure, runtime errors due to user code bugs are
unavoidable. Therefore, such Lua programs (or procedural programs in
general) have to heavily rely on runtime debug support and/or
sufficient test coverage. On the contrary, the XML programs in IoC
containers like PocoCapsule do not describe user designed procedures
but user specified requirements or results. The procedures to meet/
produce these requirements/results are arranged by the containers.
This not only largely avoids runtime errors due to user bug, but also
allows various statically verifyable integrity constraints to be
imposed on the user programs (schema validations).

> >>- to explicitly visualize the requirements/results vs to verbalize procedures that produce the implicit results.
>
> A pococapsule configuration is explicit in its types, a script indeed
> not, so pc has it's advantages here.
>
> >>- statically verifiable schema and free from runtime debug vs static grammar/type check and encourage runtime debug
>
> Very strong point of pococapsule, wrong configuration in lua-script
> cannot be determined staticaly, as such a wrong configuration could
> cause damage,
> even very late during runtime.
>
> >>- code is manipulable as first class object (i.e. code is data) vs
>
> code is intangible/protected from user code.
>
> Doesn't that also appy to the scripting code/data?
>

"Manipulating code" does not merely mean editing code using text
editor or sed, ed, awk, grep etc utilities. Otherwise, compiled binary
code (which are no more than series of binary bits) would also be
manipulable using binary editor to flipping up/down certain bits. To
be specific, "manipulate code" here is referring to the operation that
manipulates code as structural objects at user level. Lua code many
have some structure after mapping to abstract syntax trees (ASTs) (and
compiled code may also has file structure in ELF, COFF etc. formats).
However, manipulateing the code at these levels (AST or ELF/COFF) is
not only very primitive (such as only serve for simple code analysis
and refactoring) but semantically much lower than the user expressed
concepts in the original source code.

XML code in IoC containers themselves expressed user level structured
data objects. Therefore, is straightforward and seamless to be
manipulated as data objects.

> >>- code is neutral to programming language (i.e. can be manipulated by
>
> user code in any other languages) vs code is languages/
> environments
> specific.
>
> What is here the real advantage? is it that xml support is common to
> many environments?
> Then you maybe have a point, otherwise i would say "any language can
> create a script, it is
> just text", this script can be executed by the runtime environment"
> without any extra (compilation) step.
>

Firstly, generating procedural scripts/programs is usually consider a
poor practice since the failure of CASE (and UML), unless the
generated procedural code are 100% transparent to user (such as the
case of proxy generation). Otherwise, such generated procedural code
tend to be very hard to debug and maintain. Therefore, creating a
scripts from other language and execute them has no advantage.

Secondly, by "language neutral", I mean the language environment to
manipulate these code. For instance, many procedural language (such
as C++, Java, PHP, etc.) are nowaday able to be manipulated at AST
level in Eclipse environment. Although theoritically these AST
mappings are language independent, practically, they lack support
beyond the Java environment.

On the contrary, the XML to DOM mapping (and the code manipulation) is
not only at user concept level, but also available in almost all
mainstream language environments. This allows various features (such
as code verification, transformation, analysis, refactoring, etc.) and
thirday tools to be developed in very low cost without being tied to a
specific environment or being forced to write low level engines from
scratch in a new foreign environment.

Another advantage is, it does force users (especial domain users --
which may not be programmers) to learn a new procedural language.

Regards,
Ke

[Ke Jin]

I posted an article with a section discusses the XML (vs procedural/
scripting languages) in IoC containers. See:

http://www.pocomatic.com/docs/whitepapers/ioc-vs-di

Ke

On Jun 18, 1:36 am, Rick <rick.van.haa...@gmail.com> wrote: