[RkWard-devel] Code generated for "multi action" plugins

SJR stefan_roediger at gmx.de
Fri Jan 5 00:03:22 UTC 2007


Am Donnerstag, 4. Januar 2007 01:55 schrieb Thomas Friedrichsmeier:
> Hi!
>
> While reviewing some plugins, I came across an issue that we should
> probably have a policy for, but currently don't:
>
> Many plugins *can* do more than one thing. E.g. the descriptive statistics
> plugins will compute (among other things) either the mean, or the median,
> or both.
>
> Currently the code generated for that is something like:
>
> rk.temp.options <- list (domean=1, domedian=0)
> for (...) {
> 	if (rk.temp.options$domean) rk.temp.results$mean[i] <- ...
> 	if (rk.temp.options$domedian) rk.temp.results$median[i] <- ...
> }
> ...
>
> This approach has the advantage, that a user could copy the entire code
> snippet, and simply change the "domedian" option to 1 to run the same
> calculation including the median.

I wonder how many people ever will reuse the code. However, it's nice to have 
this option. And if mentioned here and there users will make use of it I 
guess. Most users see in RKWard a GUI to R anyway and not the sophisticated 
IDE. Therefore most will prefer to click here and there to get a result. At 
least this is my perception.

>
> However, another approach is to only generate code for the chosen options.
> I.e., if mean is selected, but not median, only the following would be
> generated:
>
> for (...) {
> 	rk.temp.results$mean[i] <- ...
> }
> ...
>
> While if both are selected,
>
> for (...) {
> 	rk.temp.results$mean[i] <- ...
> 	rk.temp.results$median[i] <- ...
> }
> ...
>
> would be generated. This second approach clearly has the advantage of
> keeping the generated code shorter, and more readable (at the cost of
> making the required logic to generate the code slightly more complex, but
> this would not be user visible).

On the one hand I think that people who generate code need a fast and easy way 
to do this. Therefore, it would be better to keep it simple so that everybody 
can do it easily.
But on the other hand a code that is short and more readable is preferable 
too. I consent to this point. In long term it's important to build a profound 
base. Right now most PlugIns are not really complex but this will change when 
more sophisticated PlugIns will find their place in RKWard.

>
> While writing this, I'm inclined to think the second approach is more
> elegant overall, and should be preferred. Still, the first approach is more
> prevalent in current plugins, and does have one advantage mentioned above.
> What do you think, which style we should favor in rkward?

I'm not totally sure but think the second approach is the winner for me. Maybe 
some trying and examples will help me to get totally convinced.  ;)

>
> Regards
> Thomas

Regards
Stefan


P.S.:
Policies and conventions are really important but don't forget to state them 
somewhere.




More information about the Rkward-devel mailing list