[Phylobase-devl] extractTree proposal

[Ben Bolker]

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


-- 
Ben Bolker
Associate professor, Biology Dep't, Univ. of Florida
bolker at ufl.edu / www.zoology.ufl.edu/bolker
GPG key: www.zoology.ufl.edu/bolker/benbolker-publickey.asc

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