Experiment implementing po_extract()

[hadley]

Mostly to trigger discussion. More comments below.

[MichaelChirico]

po_scan() doesn't feel like a great name to me... maybe po_snapshot()?

[hadley]

Hmmm, it seems like we're cueing off different parts of this function — it both looks for (scans) and records (snapshots) messages for translation. I wonder if we can somehow get both ideas into one word ... How about po_extract()?

[hadley]

Fixes #223. Fixes #226. Fixes #229.

[MichaelChirico]

po_extract() sounds better to me -- both make clearer the output of the function... the scanning part feels more "incidental"

[hadley]

Ok, I think this is pretty close to being done apart from the documentation — the problem is that po_extract() andget_message_data()share all of their arguments but there's no way to@inheritParams` from an .Rd file in the same package. I think there are two options:

1. Convert get_message_data() to use roxygen2
2. Duplicate the docs

Which would you prefer?

[MichaelChirico]

1. I'm happy to gradually converge on roxygen2 everywhere

[hadley]

@MichaelChirico if you want, I can do a separate PR that converts all the .Rds to roxygen (it's 95% automated). Do you want to use @export too or stick with the explicit NAMESPACE?

[MichaelChirico]

That works, esp. if it'll make it easier for you to be productive going forward (and assuming it's not a huge time drain for you).

I would keep an explicit NAMESPACE, I do prefer being more intentional there.

[hadley]

To be clear, I meant using @export to generate the NAMESPACE, so it's still intentional, but you while you're near the source of the function you can tell if it's exported or not.

[MichaelChirico]

right -- I like that but the @import / @importFrom less so.

how about using the NAMESPACE roclet but keeping all the @import/@importFrom tags in a central place (e.g. the @doctype package or .onLoad)?

[hadley]

Sure. Our current convention is to put them with the package docs anyway.