[Phylobase-devl] where are we??

[François Michonneau]

I agree with what Ben proposes. I think that the dropRoot function would
be useful. Concerning the changes in the name I agree with most of them.
I would keep the ending "s" for some accessors (*labels, nEdges, nTips,
nNodes). I would also keep the distinction between ancestor and
ancestors.

I won't be able to do much in the next couple of days as I leave for
Australia tomorrow. I arrive on January 2nd and then prepare/go to a
conference until Jan 12th. I would be surprised if I could do much until
then. I'll try to work on improving ways to add data to a phylo4d object
(but I can't guarantee I can do it before Jan 1st).

Cheers
  - François

On Tue, 2008-12-30 at 13:57 -0500, Ben Bolker wrote:
> With two days to go until supposed release, we seem to be
> stalled again (except for Francois, who just committed a patch
> for the "internal", "node", "all" consistency.
> 
>   I propose that we:
> 
> 1. merge my branch (with the aforementioned controversial
> ordering)  {Peter, can you help with this if/when we
> decide to go for it?}
> 
> 2. see what we can do to detect & fix problems with unrooted trees:
> this includes a lot of Steve's "to do" list (sorting out nodeId,
> nNode, etc.)
> 
> 3. fix problems in node labeling on plots that stem from
> the change in edge matrix format (Peter may already have a fix
> for this but was waiting on other changes)
> 
> 4.  PDC proposes that we change the NA in the root-node-row
> to (-1) instead; I propose that we add a "dropRoot" function
> (which just operates on a raw edge matrix, not on a phylo4
> object) to abstract the operation of dropping the appropriate
> row (essentially substituting for places where we have na.omit
> or edge[!is.na(edge[,1]),] in the code now
> 
> 5. make the naming-convention changes as recommended
> 
> 6. with some input from Emmanuel, implement SOME form of
> checking/consistency rule for ordering when importing/exporting
> from/to ape
> 
>   I propose that we DELAY:
> 
> 1. updating ncl to the newer version (unless Brian has this
> all ready to go)
> 
> 2. adding metadata/annotation slots, although if we know
> their GENERAL form it would be nice to add them to phylo4[d]
> objects now because adding slots later breaks backward compatibility
> of saved objects (but we may just have to bite the bullet and
> do it later).  In particular if these were slots of type list()
> we could be vague about what we were going to put in (at the
> cost of less-strong typing of the objects)
> 
> 3. everything else ...
> 
>