[Rd] Is structure(NA, class = c("def", "condition")) a valid 'condition' object?

[Tim Taylor]

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 <henrik.bengtsson using gmail.com> 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 <murdoch.duncan using gmail.com> 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
>>> 
>>> ______________________________________________
>>> R-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
> 
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel