You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
library(S4Vectors)
hits<- SimpleList(A=SelfHits(1,1,1), B=SelfHits(1,1,1))
## List of length 2## names(2): A B
endoapply(hits, sort)
## SelfHitsList of length 2## names(2): A B
Technically speaking, this is not wrong as endoapply guarantees that the return value is of the same class and a SelfHitsList is, after all, a SimpleList. But from a practical perspective, this is a bother as I cannot use the output of endoapply in the same way that I might use a SimpleList, e.g., because I can't assign non-SelfHits to it.
A closely related problem is that as(x, "SimpleList") doesn't actually create a SimpleList, but tends to try to promote things to the most specific form of a list that it can support. For example:
In fact, the behavior above is arguably incorrect because a NumericList isn't even a subclass of SimpleList.
The solution may be as simple as adding an argument to coerceToSimpleList to tell it to avoid aggressively promoting the output class within any coerce method towards a SimpleList.
Changing this behavior would likely cause a lot of problems with existing code. If you want to create an instance of a specific class, then call its constructor, SimpleList() in this case.
Btw, in the NumericList example, it's just the simplified printing that is confusing. The object is actually a SimpleNumericList.
It may be worth investigating why as() even lets us do this, since the default strict=TRUE is supposed to prevent it.
If you want to create an instance of a specific class, then call its constructor,
I think the same principle should apply to coercion: if I want to coerce to a specific class, then I should be able to coerce to that specific class. So if I want a SimpleNumericList instance, I do as(x, "SimpleNumericList"). If I want a SimpleList instance, I do as(x, "SimpleList"). This is the basic contract of coercion after all.
The only exception should be when the target class is virtual (e.g. NumericList), in which case as(x, class) is allowed to return an instance of a subclass of the specified class.
Another healthy property of coercion is idempotence i.e. as(as(x, "SomeClass"), "SomeClass") should be the same as as(x, "SomeClass") but we don't have this right now:
Consider the following example:
Technically speaking, this is not wrong as
endoapply
guarantees that the return value is of the same class and aSelfHitsList
is, after all, aSimpleList
. But from a practical perspective, this is a bother as I cannot use the output ofendoapply
in the same way that I might use aSimpleList
, e.g., because I can't assign non-SelfHits
to it.A closely related problem is that
as(x, "SimpleList")
doesn't actually create aSimpleList
, but tends to try to promote things to the most specific form of a list that it can support. For example:In fact, the behavior above is arguably incorrect because a
NumericList
isn't even a subclass ofSimpleList
.The solution may be as simple as adding an argument to
coerceToSimpleList
to tell it to avoid aggressively promoting the output class within anycoerce
method towards aSimpleList
.Session information
The text was updated successfully, but these errors were encountered: