Sylvain Wallez wrote:
Marc Portier wrote:
Sylvain Wallez wrote:
Stefano Mazzocchi wrote:
<snip />
If we match by variable name rather than by position, it would work anyway.
... but I have the feeling I'm missing a big point here.
Yeah : the point is that parameters are passed as Object[] to a JS function. The names given both in the sitemap parameters and the JS function parameters are therefore unusable for parameter passing. Only their position counts. See FOM_JavaScriptInterpreter.callFunction (line 553) : "funArgs" is a Object[].
Sylvain
Yes,
and it's quite logic since js doesn't have the notion of named argument-passing in the first place:
what I mean is that you can't have a function whatever( x, y) { return x - y; }
and then call that with:
someresult = whatever(y= 4, x= 5)
while naming the arguments by how they are declared in the function, and not deducing their role from their position
there are some scripting languages that do this IIRC, but not js
Going back to the origin of the discussion: we are calling this NOT from another js code portion, but from our beloved sitemap and there it is hard to see functional difference between
<map:call function="whatever"> <map:parameter name="x" value="5" /> <map:parameter name="y" value="4" /> </map:call>
and
<map:call function="whatever"> <map:parameter name="y" value="4" /> <map:parameter name="x" value="5" /> </map:call>
(although in strict XML infoset speak I guess there is a difference, no? (order of elements is important)
maybe it is just that other spots in the sitemap made us custom to ignoring this fact?)
One way to go about balancing of the technics and the sociologics in this could be to pass in an argument-object-map rather then multiple arguments:
so thinking about this:
function whatever(args) { dosomething(args.x); dosomething(args.y); }
we get a more natural comparison between:
someresult = whatever({y: 5, x: 4})
and:
<map:call function="whatever"> <map:arguments> <map:parameter name="y" value="5" /> <map:parameter name="x" value="4" /> </map:arguments> </map:call>
which the famous line 553 Sylvain just mentioned could easily map onto a single element Object[] to pass...
but all I did now is made some stuff more explicit...
what do you guys think, some direction for a suitable compromise?
There's already a "parameters" property in the "cocoon" object.
We can have : function whatever() { doSomething(cocoon.parameters.x, cocoon.parameters.y); }
Sylvain
yep, that crossed my mind,
but that knowledge didn't seem to stop the discussion in this thread before :-)
so I was just going for a more explicit approach that maybe did.... I have to agree that it adds to no functionality
it could make things however less arbitrary/hidden
cocoon.parameter?, or did we use cocoon.function-arguments
or was it on another object in the FOM? let's send a mail! Subject: Who remembers actively where those damn parameters are?
IMHO at this stage the thread is not any more about 'what can be functionally done' it is about 'how can we make it self describing' so we don't end up explaining this to people all over again?
in any case, it was just a proposal, and if nothing else, I hope I pointed out the source-mismatch in this.
regards,
-marc=
PS: I'ld like to understand how cocoon.parameters gets to exist since that is maybe something I coud use inside Apples as well (you know by heart where to look?)
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
[EMAIL PROTECTED] [EMAIL PROTECTED]
