[rkward-devel] JS in rkwarddev

[Thomas Friedrichsmeier]

Hi,

On Wed, 28 Oct 2015 16:26:22 +0100
meik michalke <Meik.Michalke at uni-duesseldorf.de> wrote:
> Am Mittwoch, 28. Oktober 2015, 14:54:28 schrieb Thomas
> Friedrichsmeier:
> ah, i see. well, yes, this was a bit harder to solve because of the 
> differences. however, if someone evaluated the existing JS code files
> for commonly used language constructs or functions in JS for plugins,
> i think we could make pretty much of that work with rkwarddev now.

[...]

> more importantly, you cannot simply use the iterator variable in the
> loop body, it will give you an "object not found" error when js()
> tries to make sense of the code. i tried to solve this inside the
> function, but i didn't manage. but i found a workaround and added
> that to the docs:
> 
>   i <- substitute(i) # the workaround...
> 
>   cat(rk.paste.JS(js(
>     for (i in 1:10) {
>       echo(i)
>     }
>   )))

Hmm, cool as this is, it does carry the smell of a hack. You're the
gatekeeper of rkwarddev, but my suggestion on this would be: Stow this
for-loop-code away somewhere, but don't make it (public) part of the
package, yet. Rather let's evaluate what exactly we need in this
department (if anything), and then come up with a clean solution to
cover that. Once released, people may or may not start using it, but
that will be hard to know for sure, making it difficult to change
anything later on.

> > Regarding the var names, I'd suggest to use a prefix + counter,
> > instead of pure randomness. Then at least the var names will make a
> > tiny bit of sense, if somebody is trying to read them. E.g.
> > "_RKD_for_array_1" and "_RKD_for_index_1", or something like that.
> 
> but what happens if someone decides to use two nested for loops,
> wouldn't the second overwrite the variables?

In spite of the above: Well, my idea would have been that the next loop
will get "_RK_for_array_2" and "_RKD_for_index_2". Of course that would
mean rk.paste.JS would have to keep track of which names have already
been assigned.

One additional problem about random names is these would cause noise in
the diffs when re-generating files.

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20151028/344365e4/attachment.sig>