R help - Aug 2023 - Use generic functions, e.g. print, without UseMethod?

Hello,

I have defined a function 'equations(...)' which returns an object with 
class 'equations'. I also defined a function 'print.equations'
which
prints the object. But I did not use 'equations <- function(x, ...) 
UseMethod("equations"). Two questions:

1.) Is this a sensible approach?
2.) If yes, are there any pitfalls I could run in later?

Thanks

Sigbert

-- 
https://hu.berlin/sk
https://www.stat.de/faqs
https://hu.berlin/mmstat
https://hu.berlin/mmstat-ar

On Fri, 11 Aug 2023 09:20:03 +0200
Sigbert Klinke <sigbert at wiwi.hu-berlin.de> wrote:
> I have defined a function 'equations(...)' which returns an object
> with class 'equations'.
> But I did not use 'equations <- function(x, ...)
> UseMethod("equations"). Two questions:
> 
> 1.) Is this a sensible approach?
Quite. If there is little reason for your constructor to be generic
(i.e. there is only one way to construct "equations" objects), it can
stay an ordinary R function. lm() works the same way, for example, and
so do many statistical tests and contributed model functions.
> 2.) If yes, are there any pitfalls I could run in later?
If it later turns out that you need S3 dispatch on the constructor too,
you will need to take care to design its formals to avoid breaking
compatibility with the old code. Ideally, the generic should take (x,
...), with the first argument determining the method that will be
called. If that would conflict with the already-existing code, the
generic can have a different signature and give a different objectargument to
UseMethod(), but the methods will have to follow the
signature of the generic.

-- 
Best regards,
Ivan

?s 08:20 de 11/08/2023, Sigbert Klinke escreveu:
> Hello,
> 
> I have defined a function 'equations(...)' which returns an object
with
> class 'equations'. I also defined a function
'print.equations' which
> prints the object. But I did not use 'equations <- function(x, ...) 
> UseMethod("equations"). Two questions:
> 
> 1.) Is this a sensible approach?
> 2.) If yes, are there any pitfalls I could run in later?
> 
> Thanks
> 
> Sigbert
> 
Hello,

You have to ask yourself what kind of objects are you passing to 
'equations(...)'?
Do you need to have

'equations.double(...)'
'equations.character(...)'
'equations.formula(...)'
'equations.matrix(...)'
[...]

specifically written for objects of class

numeric
character
formula
matrix
[...]

respectively?
These methods would act on the respective class, process those objects 
somewhat differently because they are of different classes and output an 
object of class "equation".
(If so, it is recommended to write a 'equations.default(...)' too.)

Methods such as print.equation or summary.equation are written when you 
want your new class to have functionality your new class' users are 
familiar with.

If, for instance, autoprint is on as it frequently is, users can see 
their "equation" by typing its name at a prompt. print.equation would 
display the "equation" in a way relevant to that new class.

But this does not mean that the function that *creates* the object needs 
to be generic, you only need a new generic to have methods processing 
inputs of different classes in ways specific to those classes.

Hope this helps,

Rui Barradas