[Phylobase-devl] labels() and other questions

[Brian O'Meara]

>>> 2) Another small concern I have is about the way functions  
>>> returning a
>>> component or a simple information about a phylo4/phylo4d are named:
>>> we have a "hasNodeLabels", a "nTips", or a "rootNode" but we have
>>> "NodeLabels" and "EdgeLength" (not "nodeLabels" and "edgeLength") to
>>> give a few examples. This is annoying when looking for a function...
>>> like typing "node" then [tab][tab] does not list all 'node'  
>>> functions.
>>> Another related issue is about already existing functions, i.e.  
>>> from the
>>> required packages. Looking for node labels, I was mislead by ape's
>>> functions "tiplabels", "nodelabels" and "edgelabels" which  
>>> actually do a
>>> different job (add labels to a plot).
>
>    Well, there is at least a distinction between hasNodeLabels and
> NodeLabels -- the first is (verb+noun), the second is just (noun).
> On the other hand, rootNode doesn't make sense according to this
> scheme.
>   Furthermore, Brian's functions are even more camel-case-y:
> e.g. NexusToPhylo4 (which I would call read.nexus or something like
> that).
>   If we want to use the most "sensible" labels we may start running
> into trouble with ape conflicts (as suggested by Thibaut, above) --
> is it time for a namespace yet?  Will that fix all our problems?

I'm more than happy to change (or have changed) the IO function names  
to have them consistent with general R/phylobase style. Ape conflicts  
may be a problem, there, too (such as read.nexus). There's also the  
issue of having one input format (nexus) and multiple output  
structures (tree, data, or tree+data object). Currently, this is  
handled by NexusToPhylo4, NexusToDataFrame, and NexusToPhylo4D. I  
don't know the best style: does one add a suffix to indicate the  
target ("read.nexus.phylo4d"), add the target type as an argument to  
a single read.nexus function, or some other approach?

Brian