Scripting Languages (was Re: Less is more... or less? (was Re: v2 forms flowscript example))

[Christopher Oliver <re...@verizon.net>]

Sylvain Wallez wrote:

> Vadim Gritsenko wrote:
>
>>>> Sylvain Wallez wrote:
>>>>
>>>>> Why is there a need to have a different API for widgets when used 
>>>>> from JS than when used from Java? IMO, this is arbitrarily 
>>>>> limiting the features available in flowscript.
>>>>
>>>>
>>
>> But isn't this our design approach? If I remember correctly our FOM 
>> discussions, "less is more", right?
>
>
>
> Well, time for a bit of rant on this.
>
> I'm personally not that happy with "less is more" as it was applied to 
> FOM. Although I agree that bloated APIs should be avoided, restricting 
> the Cocoon core APIs (the environment) in some specific area of Cocoon 
> (flowscript) seems to me an arbitrary constraint.
>
> Yes, not that many people have asked for more of the Java environment 
> APIs to be visible. But why so? Simply because people (and I talk 
> about what I've seen in real customer projects) often end up writing a 
> simple Java class that allow them to access the real Java object and 
> therefore use the *full* environment API in their flowscripts. This 
> leads to clumsy constructs that overcomplexify the flow scripts.
>
> That's why I don't like the JS-specific APIs, except those that allow 
> shorter notations through properties.
>
> Furthemore, this makes learning more difficult, as people have to 
> learn *two* APIs to know what is (or is not) available in flowscript. 
> And as we have no explicit auto-generated documentation for the 
> flowscript APIs, this is a lot of trial and error. 

Well, the JS Flowscript API is documented: 
http://cocoon.apache.org/2.1/userdocs/flow/api.html.

Although I agree with you that there should not be unnecessary 
limitations in the JS API  as compared to Java, nevertheless I think 
it's unavoidable that there will be some differences. This seems to be 
the case more generally with any Java scripting language. For example, 
JS String and java.lang.String do not have the same API:

   var length = "Hello".length;
   var length = new java.lang.String("Hello").length();

Compare also JS DOM versus Java DOM. I really don't see how such 
mismatches can be avoided completely. You'll run into the same thing 
with Jython, Groovy, etc. The net result of this is that, yes, the user 
will have to learn two API's (although similar).

Nevertheless, at least in my experience the combination of a scripting 
language and a system programming language has always been a winning 
combination. At my previous company, we developed tools for the abstract 
syntax language ASN.1. We provided a mapping to C++ classes, but we also 
implemented an ASN.1 API for the TCL scripting language. In constrast to 
JS/Java, TCL syntax is drastically different from C++. So the API's were 
not identical but however provided equivalent functionality in their own 
way. With the close similarity between JS and Java syntax it's tempting 
to try to make the API's identical, but there are important features 
only in JS (first class functions, closures, etc) that can and should be 
exploited.

My opinion is that any Cocoon JS API's should be developed to provide 
the best possible JS programming environment for the user. If this 
results in a different API than that provided in Java, so be it 
(although I think we should strive to make them the same where possible).

Chris