> May be the best thing is that you give it a try, and build the first
> version of the package according to your vision. Then if I still think
> that my approach is more parsimonious I will give a rewrite. Afterward
> we can talk in more concrete terms.
I think that's a really good idea :) Thank
>> Hadley Wickham
>> on Thu, 30 Aug 2012 15:07:37 -0500 wrote:
>>
>> No, no ... that was precisely the main point! It should process each
>> *tag* at "package level". Then process each *tag* at a "block level" and
>> finally at "tag level". Here is the complete pseudo code for roxy
On Thu, Aug 30, 2012 at 2:12 PM, Vitalie Spinu wrote:
> >> Hadley Wickham
> >> on Thu, 30 Aug 2012 11:29:07 -0500 wrote:
>
>
> >> So roxygenize will iterate 3 times over all tags and call prepareTag on
> >> first iteration, then prepareDoc, and finally preparePackage.
>
> > That's bette
>> Hadley Wickham
>> on Thu, 30 Aug 2012 11:29:07 -0500 wrote:
>> So roxygenize will iterate 3 times over all tags and call prepareTag on
>> first iteration, then prepareDoc, and finally preparePackage.
> That's better, but generally you only need to call preparePackage
> once, not
> How about this. You can have 3 levels on which a tag can perform an
> aciton -- a local tag level, on the object documentation (block) level
> and on a package level. For each of this actions you have a generic
> dispatched on *tag* object:
>
> setGeneric("prepareTag", function(tag) standardGene
>> Hadley Wickham
>> on Thu, 30 Aug 2012 08:57:41 -0500 wrote:
>> I have done my best here https://gist.github.com/3516476
> Thanks - that's useful. A few comments/questions:
> * I don't think the spec for processTag is quite right yet - currently
> you have it returning a transforme
> * Similarly, I still don't see how tags that operate globally would
> work. I think that's partly because the model is so focussed on the
> individual tag - the tag classes become very heavy - that's where all
> the logic is stored. That's not such a good fit for actions that work
> on multiple
> I have done my best here https://gist.github.com/3516476
Thanks - that's useful. A few comments/questions:
* I don't think the spec for processTag is quite right yet - currently
you have it returning a transformed object of the same class as the
input - but that only works for a limited number
I have done my best here https://gist.github.com/3516476
In what follows, I use the same names as in my gist outline, in an
attempt to influence you in the naming matter of course ;).
>> Hadley Wickham
>> on Wed, 29 Aug 2012 12:25:19 -0500 wrote:
> Object seems a bit awkward because it's
On Wed, Aug 29, 2012 at 12:00 PM, Vitalie Spinu wrote:
> >> Hadley Wickham
> >> on Wed, 29 Aug 2012 09:07:41 -0500 wrote:
>
> > Hi Vitalie,
> > It would also be really useful if you could sketch out the S4 design
> > to work with a tag like usage.
>
> > Would you need multiple dispatc
>> Hadley Wickham
>> on Wed, 29 Aug 2012 09:07:41 -0500 wrote:
> Hi Vitalie,
> It would also be really useful if you could sketch out the S4 design
> to work with a tag like usage.
> Would you need multiple dispatch so that usage looks like:
> setMethod("ProcessTag", signature(tag
Hi Vitalie,
It would also be really useful if you could sketch out the S4 design
to work with a tag like usage.
Would you need multiple dispatch so that usage looks like:
setMethod("ProcessTag", signature(tag = "RoccerUsage", object =
"function"), ...)
setMethod("ProcessTag", signature(tag = "Ro
12 matches
Mail list logo
