[Phylobase-devl] extractTree proposal

[Jim Regetz]

Ben Bolker wrote:
>   this sounds sensible.  the only concern I have (and perhaps the reason
> we originally set things up in what has now come to be a slightly
> bass-ackwards way) is that we have a warning message issued on coercion
> from phylo4d to phylo4 ("data lost"), which we don't with the explicit
> extractTree function (because there we assume that's what the user
> really wants to do).  Is there a way to achieve this behavior with
> your approach? (I guess we could use suppressWarnings(as(...)) but
> that would suppress *all* warnings?)

Hmm, I only see the warning when coercing to phylo4d to phylo, not to 
phylo4. Looks like there once *was* an explicit phylo4d->phylo4 coerce 
method that produced the warning, but it's commented out. A note in the 
comments (yours?) points out that the explicit coerce method, with 
warning, would make for very noisy evaluation of all inherited methods. 
I agree! And I don't think we need to warn about dropping data, given 
that a fundamental phylobase concept is that phylo4d objects include 
data whereas phylo4 objects do not.

So unless I'm missing something, if the plan is to continue to rely on 
the implicit coercion, than there won't be an issue with extractTree.

Jim

> Jim Regetz wrote:
>> Hi all,
>>
>> The extractTree function currently extracts the tree part of a phylo4d 
>> object by manually accessing each relevant phylo4 slot and passing them 
>> to the phylo4('matrix') constructor. I'd like to propose this instead:
>>
>> extractTree <- function(from) as(from, "phylo4")
>>
>> Note that this "as" method requires no maintenance on our part, because 
>> it is derived implicitly from the class definition of phylo4d as an 
>> extension of phylo4. You can use this incantation to see the method:
>>    selectMethod("coerce", c("phylo4d", "phylo4"))
>>
>> Defining extractTree this way makes it faster and simpler, and also more 
>> robust to other code changes. It also means that if there are problems 
>> with the phylo4d object, an error will come from checkTree rather than 
>> the phylo4 constructor, which IMHO is more sensible. If future changes 
>> require a more complicated approach, we can deal with it then (and it 
>> will still just be extractTree to the end user, which is a good reason 
>> not to drop this function altogether).
>>
>> Thanks,
>> Jim
>> _______________________________________________
>> Phylobase-devl mailing list
>> Phylobase-devl at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl
> 
>