[Phylobase-devl] extractTree proposal

[Jim Regetz]

Done.

Looks like a similar trick can be applied to the phylo4d("phylo4") 
method, which would diff something like this:

-    ## Creating new phylo4d object
-    res <- new("phylo4d")
-    res at edge <- x at edge
-    res at edge.length <- x at edge.length
-    res at Nnode <- x at Nnode
-    res at tip.label <- x at tip.label
-    res at node.label <- x at node.label
-    res at edge.label <- x at edge.label
-    res at order <- x at order
+    ## coerce to phylo4d
+    res <- as(x, "phylo4d")

      ## taking care of the data
      tmpData <- .phylo4Data(x=x, tip.data=tip.data, node.data=node.data,
                             all.data=all.data, match.data=match.data,
                             merge.data=merge.data,
                             rownamesAsLabels=rownamesAsLabels, ...)

      res at tip.data <- tmpData$tip.data
      res at node.data <- tmpData$node.data
      res at metadata <- metadata

Note that this change will also "automatically" pick up the new annote 
slot, which otherwise gets lost without a new line of code to transfer 
the slot value explicitly.

I'll test and apply if no one has objections.

Jim

Ben Bolker wrote:
> Jim Regetz wrote:
>> 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
>>
> 
>   OK, then, your plan sounds fine to me.
> 
>   Ben
> 
> 
>>> 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
> 
>