[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