hi,

Am Sonntag, 17. Februar 2013, 10:57:38 schrieb Thomas Friedrichsmeier:
> I'm having lots of real-life distraction ATM, so my feedback will be coming
> in a piecemeal fashion:

no problem ;-)

> >   - rk.XML.switch()
>
> Generated code looks correct to me. However,

thanks, that's the most important news :-)

> a) An example for using case and default would be really helpful.

done -- and i hope it's what is intended?

> b) Perhaps the function signature could be simplified to
>
> rk.XML.switch(condition, modifier = NULL, cases, id.name = "auto")

yeah, i was thinking about something similar when i started, but somehow lost
it. i must say it took me a good deal of thinking to understand all those new
nodes with all options and their implications, and i'm not sure whether i got
it all right, so it's well appreciated that you do some checking.

i've simplified it now, but it's a little different from what you suggested:

> # if there are exactly two cases, and their standards are logical(!)
> TRUE/FALSE, generate a true/false switch
> rk.XML.switch ("foo", cases = list (
>     list (standard=TRUE, fixed_value="foo"),
>     list (standardúLSE, fixed_value="bar")
> ))

this is now

rk.XML.switch ("foo", cases = list (
    true = list (fixed_value="foo"),
    false = list (fixed_value="bar")
))

> # otherwise a "case" switch. If the final case specification has no standard
> (or standard=NULL), make it a <default>.
> rk.XML.switch ("foo", cases = list (
>     list (standard="square", fixed_value="foo"),
>     list (standard="circle", fixed_value="bar"),
>     list (fixed_value="other")
> ))

and this would be:

rk.XML.switch ("foo", cases = list (
    case = list (standard="square", fixed_value="foo"),
    case = list (standard="circle", fixed_value="bar"),
    default = list (fixed_value="other")
))

i preferred it this way because it's a little more consistent with the output,
especially since "standard" is supposed only to be valid for <case> nodes
(therefore i'd find "standard=TRUE/FALSE" to indicate <true/false> nodes a bit
confusing). it's a bit more to write for <case> stuff, but at the same time,
the original intention of a plugin author is documented.

what do you think?

the <optionset> docs do also still need more examples.


viele grüße :: m.eik

--
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at d-40204 d"usseldorf

Attachment: signature.asc
Description: This is a digitally signed message part.

------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Reply via email to