> On 01.05.2006 17:51, Christopher Nelson wrote:
> > This is one of the most user-visible areas for AWS2, and I have
> > already received some suggestions on it. However, I want
> to have user
> > consensus before I commit to changing this.
>
> The problem I see with both suggestions you made is that you
> provide a way to associate user-defined data with a script
> object created from client code; this severely limits its usefulness.
I don't believe you are correct in your interpretation.
> Even the most simple C callback mechanisms usually provide
> some kind of "user data" argument that allows you to re-use
> the same function but with different variables/structures
> etc. that the callback function can use - cheap OOP.
>
> You should seriously consider providing a way to supply both
> a function and user-data. C++ should offer a couple of ways
> for that; interfaces come to my mind, maybe pointers to
> non-static member functions...
I feel that many might not realize how it's intended to be used.
First of all, the creation phase requires you to provide a name that
will be used as the notification object. This is a full javascript
object. So in your script code, you may want to do something like this:
---
// Setup some helpers for the particleFountain object.
particleFountain.Stop = function()
{
var stopCmd = 0;
particleFountain.onEvent(stopCmd);
}
particleFountain.Start = function()
{
var startCmd = 1;
particleFountain.onEvent(startCmd);
}
---
You may also set various properties of the object that are viewable from
native code. You can create properties from native code as well.
Therefore, the current interface allows access to all of this richness.
Note that most of the interaction with script objects should be done in
script.
I firmly believe that the simplest solution that works is the correct
one. Providing a number of different ways to create a callback or
notification event makes no sense in this context. Why?
For one thing, AWS2 itself *never* triggers your notification event.
Therefore, it's only done by signals from the script side of things.
Javascript itself has only three data types, integer, double, string.
There are other built-in objects, but they are not primitive types.
Being able to accept and post more sophisticated objects would require
your app to be more tightly bound to the JS api. In that case, you will
not be using AWS2's simple interface.
For another thing, JS is a C api. The native code API has one, and only
one, signature. The script interface simplifies the process of using
the JS callback mechanism, and of getting and setting arguments and
properties. It therefore provides simple access to *all* of the
information that a simple interface can have access to.
If you still feel that your idea has merit and that I am perhaps missing
the point, please provide me with a practical use case that demonstrates
your preferences.
-={C}=-
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Crystal-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe: mailto:[EMAIL PROTECTED]
