[Phylobase-devl] labels() and other questions

[Ben Bolker]

Marguerite Butler wrote:
> 
> On Feb 28, 2008, at 1:11 AM, Thibaut Jombart wrote:
> 
>> Hi phylobasists,
>>
>> 1) considering the current implementation of labels() labels(x) returns
>> the tip labels of 'x'), I was thinking that I would prefer to have it
>> return the labels of all nodes and tips, that is, associating a label to
>> each number in @edge.
>> Anyony voting against this modification, or having an advice?
>>
> 
> YES! A strong vote in favor of returning all node labels (internal + 
> tip). I personally get very confused about the numbering of nodes on the 
> tree, and this would help avoid a serious mistake. I would really like 
> to avoid breaking up the structure of the data object into pieces, it's 
> safer to keep it whole. Especially since labels() is so generic.. it's 
> not tip.labels() after all, so I would expect the default behavior to 
> return all labels anyway.
> 
> Perhaps one solution would be to have an option labels( tree, 
> tips.only=FALSE)  or a type="tips", "internal", etc.?

   Fine with me.  (The "labels" generic does have a ... in it
[unlike "show"], so we can use optional arguments -- I would
vote for type=c("all","tips","internal","edges") {where "all"=
"tips+internal"})
   I think the reason it was done this way in the first place was my 
guess that end-users (as opposed to programmers) were more likely
to want just the tip labels more often.  But I guess they can
use a special "tiplabels" instead (should we call it "tip.labels"
or "tip_labels" instead to avoid ape conflicts?
   labels() with options would at least get rid of some of the
NodeLabels, EdgeLabels, etc. stuff -- although it could be a little
clunky if people want to get labels(x,"internal") on a regular basis
(NodeLabels(x) is a little shorter).
   ape should really have called its functions label_tips,
label_nodes, label_edges (or some such).
> 

> 
>> 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?

>> In an ideal world, I guess, we would be using a generic
>> way-of-naming-functions... any idea about what we can do in the real 
>> world?
>>
> 
> We definitely need some consistency. It is not obvious to me what the 
> scheme should be however. The lower case form looks more like 
> conventional R code, but I don't have a strong feeling as long as it is 
> a coherent system.
> 
> We should probably fix this before it goes further and gets more out of 
> hand, though.

   I still have a question about tree-walking functions such as
"get ancestors", "get descendants" etc. -- Hilmar points out that
"get" is not normally used in R, and I'm fine with all lowercase
rather than CamelCase as being more R-like, but: are they called

sons/parents
daughters/parents
descendants/ancestors
nodes, branches, edges, leaves, ... ?

   Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://lists.r-forge.r-project.org/pipermail/phylobase-devl/attachments/20080229/6f989fae/attachment.pgp