FWIW - I read this the same way as you Henrik. I presume if there was a desire to restrict the underlying typeof the condition a dedicated constructor would have been supplied and the type enforced. Whether this would be better or worse is an interesting thing to ponder.
Tim > On 8 Oct 2025, at 16:43, Henrik Bengtsson <[email protected]> wrote: > > Thank you, Duncan. > > It sounds like you're reading it the same as I, i.e. what > typeof(<condition>) should be is not specified. > > Using list() in my tiny example was a thinko - NULL would indeed have > been better. > > /Henrik > >> On Wed, Oct 8, 2025 at 5:32 AM Duncan Murdoch <[email protected]> >> wrote: >> >> Besides `conditionMessage` and `conditionCall`, base R also has methods >> defined for `as.character` and `print`, but they appear to make no >> assumptions about the object other than having `conditionMessage` and >> `conditionCall` defined. >> >> The help page is silent about what type of thing `conditionCall()` >> should return, but the objects produced by the standard condition >> functions will return the `call` argument, which defaults to `NULL`, but >> could be a "call expression". >> >> So I'm not sure your definition of the `conditionCall()` methods is >> going to work: `list()` doesn't return an expression. Returning >> `NULL` would be better. >> >> Of course, in S3 "valid" isn't defined formally; it just means something >> that won't mess up. So it's quite possible `list()` is okay. >> >> Duncan Murdoch >> >> >>> On 2025-10-07 7:42 p.m., Henrik Bengtsson wrote: >>> I think structure(NA, class = c("def", "condition")) is a valid >>> 'condition' object. Am I wrong? >>> >>> BACKGROUND: >>> >>> The abstract 'condition' class: why type or mode can a 'condition' object >>> have? >>> >>> In help("condition"), we can read that: >>> >>> "Conditions are objects inheriting from the abstract class condition. ..." >>> >>> and then it specifies the API, i.e. the methods it should support, e.g. >>> >>> "The functions conditionMessage and conditionCall are generic >>> functions that return the message and call of a condition." >>> >>> Then we have several functions for creating 'condition' objects, e.g. >>> >>>> simpleCondition >>> function (message, call = NULL) >>> { >>> class <- c("simpleCondition", "condition") >>> structure(list(message = as.character(message), call = call), >>> class = class) >>> } >>> >>> AFAIK, all of them create 'condition' object of type 'list'. >>> >>> >>> CAN CONDITIONS BE ENVIRONMENTS OR ATOMIC OBJECTS? >>> >>> However, is the list type a requirement? I cannot find it specified >>> anywhere. The way I interpret help("condition") and how it is >>> carefully written using terms like "abstract class" and not mentioning >>> the type anywhere, I take it as: >>> >>> cnd1 <- structure(new.env(), class = c("abc", "condition")) >>> >>> and >>> >>> cnd2 <- structure(NA, class = c("def", "condition")) >>> >>> are both valid 'condition' objects, as long as we define the S3 >>> methods for `conditionMessage()` and `conditionCall()`, e.g. >>> >>> conditionMessage.abc <- function(c) "boom" >>> conditionCall.abc <- function(c) list() >>> >>> conditionMessage.def <- function(c) "boom" >>> conditionCall.def <- function(c) list() >>> >>> FWIW, I create 'condition' objects of type NA in my 'R.oo' package >>> going back ~25 years. >>> >>> Thanks, >>> >>> Henrik >>> >>> ______________________________________________ >>> [email protected] mailing list >>> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > ______________________________________________ > [email protected] mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
