Hi, On Friday 12 August 2011, meik michalke wrote: > i've added roxygen2(!) style comments to the functions in the rkward R > package.
great!
> not writing new docs, just using Rd2roxygen on the present Rd
> files. i stumbled across this in public.R:
>
> <code>
> # utility to convert the rkward meta data of objects created in rkward <
> 0.4.0 # keep for a few months after 0.4.0 is out
> "rk.convert.pre040" <- function (x) {
> ...
> </code>
>
> is that still used?
I think, you can safely remove that.
> another question i have is regarding the destinction between "internal" and
> "public". all "internal" functions are actually publicly available, many of
> them are just hidden because their name starts with a dot. is that for a
> reason? if this was not intended, i could add @export tags only where they
> belong.
>
> for the really public functions i would like to split the public.R file
> into one file per linked group of functions, if that's ok.
Yes, go ahead.
Regarding "internal" versus "public" functions: Yes, currently the intended
usage of functions is indicated by whether or not their name starts with a
dot.
Some time ago, Prasenjit asked, why we don't use a proper namespace for
"internal" functions. The answer is that there is no good reason, why we
don't. However, if we do move internal functions to a namespace (as non-
exported symbols), then some adjustments will be necessary in the frontend.
This is because the frontend uses these functions as if they were publicly
accessible. So that would have to be done very carefully (mostly be grep'ping
the sources for each "internal" function name, then replacing all uses in the
frontend with rkward:::.rk.something(), appropriately, then testing).
Regards
Thomas
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
