On Mon, Nov 14, 2011 at 11:57 AM, Michael Lawrence
wrote:
>
>
> On Mon, Nov 14, 2011 at 9:21 AM, Hadley Wickham wrote:
>>
>> > In roxygen (v1) existing Rd files in the Rd directory are merged with
>> > the documentation generated by roxygen based on the file name and
>> > @rdname.
>> >
>> > Maybe
> Yes that's true. BTW: that reminds me that it would be nice to
> have an indicater in Rd files which says that this Rd file is
> generated by roxygen (maybe a comment). Would make a "make clean"
> easier.
https://github.com/klutometis/roxygen/issues/69
Hadley
--
Assistant Professor / Dobelma
> To add on to this a little bit, there needs to be convenient support for
> generating NAMESPACE imports.
>
> If a class is included in a method signature, or is passed in "contains" to
> setClass(), and it is not defined within the package, Roxygen should search
> the dependent packages for a cla
To add on to this a little bit, there needs to be convenient support for
generating NAMESPACE imports.
If a class is included in a method signature, or is passed in "contains" to
setClass(), and it is not defined within the package, Roxygen should search
the dependent packages for a class of the s
On 11/14/11 6:21 PM, Hadley Wickham wrote:
In roxygen (v1) existing Rd files in the Rd directory are merged with
the documentation generated by roxygen based on the file name and
@rdname.
Maybe we can implement something similar in roxygen2? Would that help?
I really don't like mixing generate
On Mon, Nov 14, 2011 at 9:21 AM, Hadley Wickham wrote:
> > In roxygen (v1) existing Rd files in the Rd directory are merged with
> > the documentation generated by roxygen based on the file name and
> > @rdname.
> >
> > Maybe we can implement something similar in roxygen2? Would that help?
>
> I
> In roxygen (v1) existing Rd files in the Rd directory are merged with
> the documentation generated by roxygen based on the file name and
> @rdname.
>
> Maybe we can implement something similar in roxygen2? Would that help?
I really don't like mixing generated and hand-written files in the
same
>> There may be a use-case for @including Roxygen comments, but I think my
>> use-case would benefit more from pure Rd that would just be concatenated
>> into the resulting Rd file. These would be things like extra \section{}s.
>> Maybe make that more explicit with a @section that refers to a file?
Ah, simultaneous post, perhaps to merge both use cases:
On Mon, Nov 14, 2011 at 10:51 AM, Michael Lawrence
wrote:
>> That's another interesting idea. We currently have @template, which
>> is a superset of @include, but it might be worthwhile differentiating
>> them semantically. Where would yo
> One last thing: documentation for classes can get pretty long. Is
there a
> way to @include extra files? Steve Lianoglou had this idea.
That's another interesting idea. We currently have @template, which
is a superset of @include, but it might be worthwhile differentiatin
Hi,
Lots of great ideas there.
Just to comment on this one:
On Mon, Nov 14, 2011 at 10:08 AM, Hadley Wickham wrote:
>> One last thing: documentation for classes can get pretty long. Is there a
>> way to @include extra files? Steve Lianoglou had this idea.
>
> That's another interesting idea.
On Mon, Nov 14, 2011 at 7:08 AM, Hadley Wickham wrote:
> > Although in many cases one could create such class-based
> methods
> > with simple functions, if someone wants to override one in a subclass,
> they
> > will need to create a method (which would create an implicit generic,
> > defaulting
> Although in many cases one could create such class-based methods
> with simple functions, if someone wants to override one in a subclass, they
> will need to create a method (which would create an implicit generic,
> defaulting to the original function). Usually though, that implicit generic
> is
Hey guys,
These are the two basic design approaches when it comes to S4 programming:
1) Generic-centric: This corresponds to Hadley's first classification and
is the "functional OOP" style, where there is a function that is "extended"
with methods.
2) Class-centric: This is the conventional clas
> For the most part, packages that I've written (and am currently writing) have
> complex classes that store and process a large amount of data. There are
> usually many generics with only a single method each. The xcms package has
> several such classes:
>
> http://www.bioconductor.org/packages
I'm developing a new, relatively complex, R package right now. It's been a
while since I've done so and had more recently been doing a lot of C++
programming with Doxygen. I've found manually maintaining Rd files to be a real
pain, and was really happy to find Roxygen.
For the most part, packag
Hi all,
I've been spending some time thinking about how to document S4
methods, and I've included my current thoughts so far. I'd really
appreciate your feedback, so we can get roxygen2 working well with S4.
# Methods
Two types of generics:
* Large number of simple methods such as in the Matri
hi hadley,
Am Dienstag 25 Oktober 2011, 14:16:15 schrieb Hadley Wickham:
> Starting to look into improving roxygen2's S4 support. Does any one
> have a good set of test cases? (e.g. simple package that uses S4 and
> has good documentation).
have a look at
o http://reaktanz.de/?c=hacking&s=XiMp
Hi all,
Starting to look into improving roxygen2's S4 support. Does any one
have a good set of test cases? (e.g. simple package that uses S4 and
has good documentation). I'm also interested in full list of
outstanding issues so that I can squash them all at once.
Hadley
--
Assistant Profess
19 matches
Mail list logo
