[Phylobase-devl] node retrieval / recapitulation
Peter Cowan
pdc at berkeley.edu
Thu Mar 6 00:33:09 CET 2008
On Mar 5, 2008, at 2:43 AM, Thibaut Jombart wrote:
> To recap with the nomenclature:
> - "tips", "edges": seems to have a consensus on that
Agreed.
> - "nodes": equals 'internal nodes' (has my vote) /vs/ all nodes
> (tips +
> internal)
I'm torn here, I'll be fine with either decision. I do think that we
need not feel bound by the decisions of ape. One of the motivations
for phylobase is that ability to make changes to the ape approach.
> - "NexusToPhylo4" (and related IO functions): there seems to be a
> consensus for changing the name, and using an argument to specify the
> output; "read.nexus" would conflict with ape, but this may be solved
> by
> using a namespace (is this overkill?); Hilmar suggested naming the
> function from the content read (phylogeny / comparative data) rather
> than from the format (newick, nexus, ...). I think content is more
> generic, but I find it more visible to have a read.[format].
I don't think a namespace is overkill, but that said, I haven't
wrapped my head around them. I would prefer names such as
read.fileformat(), like read.csv(), unless we could reliably write a
function that would detect the format and dispatch the proper method -
which is probably more work than it is worth.
> - naming functions: there seems to be a consensus about the
> "camelCase"
> (i.e. "lowerCamelCase" rather than "UpperCamelCase").
I would also favor singleCamel, rather than doubleCamelCase.
> Appart from this, one colleague here is presently using/crash-testing
> phylobase - as an enduser -, and I begin to receive good feedback
> (among
> bunches of "why is this not working?!?"). A good point for us all, I
> guess.
That is both exciting and scary. Your colleague should feel free to
join the mailing list and complain to the lot of us, if s/he is willing.
Peter
More information about the Phylobase-devl
mailing list