From m@echler @ending from @t@t@m@th@ethz@ch  Sun Dec 23 16:46:54 2018
From: m@echler @ending from @t@t@m@th@ethz@ch (Martin Maechler)
Date: Sun, 23 Dec 2018 16:46:54 +0100
Subject: [Rd] formula(model.frame(..)) is misleading
In-Reply-To: <3A66F355-79A3-4E1F-BADF-9773BBCEA02E@mcmaster.ca>
References: <CAF8bMcaSrPfpdJMOeDg0ptJBLJrZvOJiEy7Bdkf3-oZZwNYnuw@mail.gmail.com>
 <27876_1545378678_wBL7pHYd012851_23580.39786.529658.257284@stat.math.ethz.ch>
 <3A66F355-79A3-4E1F-BADF-9773BBCEA02E@mcmaster.ca>
Message-ID: <23583.44526.687250.675390@stat.math.ethz.ch>

>>>>> Fox, John 
>>>>>     on Fri, 21 Dec 2018 16:16:40 +0000 writes:

    > Dear Martin,

    > Since no one else has picked up on this, I?ll take a crack
    > at it:

Thank you, John

    > The proposal is to define the S3 class of model-frame
    > objects as c(?model.frame?, ?data.frame?) (not the formal
    > class of these objects, even though this feature was
    > coincidentally introduced in S4). That?s unlikely to do
    > harm, since model frames would still ?inherit? data.frame methods.

Well, sure, "in theory".
My fear is different -- and I think for good reasons :

IIRC, I've seen slides of a talk by a well respected R
community member where they advertized  -- IIRC, even as example
of good R programming --  to use

  switch(class(obj)[1],
         "foo" = { ....  some things .... },
	 "bar" = { ....  other things .... },
	 .....
	 stop("invalid class ", class(obj)[1])

        )

and I have seen many package authors use analogously "broken" R
code

  if(class(obj) == "foo") { # deal with "foo" ...
    ....
  } else if(class(obj) == "bar") {
    ...
  } else .....

all of which will fail if users of that code (including other
package writers) decide to extend that S3 class  using a
length(class(.)) >= 2  ....

Now, with Bill Dunlap's findings about S-plus 8.3, namely that
it does not contain a *single*  model.frame method,
I'd rather tend to only  fix formula.data.frame()

Martin



    > It's possible that some packages rely on current
    > data.frame methods that are eventually superseded by
    > specific model.frame methods or do something peculiar with
    > the class of model frames, so as far as I can see, one
    > can?t know whether problems will arise before trying it.

    > I hope that helps, John

    >   -------------------------------------------------
    >   John Fox, Professor Emeritus McMaster University
    > Hamilton, Ontario, Canada Web:
    > http::/socserv.mcmaster.ca/jfox

    >> On Dec 21, 2018, at 2:51 AM, Martin Maechler
    >> <maechler at stat.math.ethz.ch> wrote:
    >> 
    >>>>>>> William Dunlap via R-devel on Thu, 20 Dec 2018
    >>>>>>> 15:09:56 -0800 writes:
    >> 
    >>> When formula() is applied to the output of model.frame()
    >>> it ignores the formula in the model.frame's 'terms'
    >>> attribute:
    >> 
    >>>> d <- data.frame(A=log(1:6), B=LETTERS[rep(1:2,c(2,4))],
    >>>> C=1/(1:6),
    >>> D=rep(letters[25:26],c(4,2)), Y=1:6)
    >>>> m0 <- model.frame(data=d, Y ~ A:B) formula(m0)
    >>> Y ~ A + B
    >>>> `attributes<-`(terms(m0), value=NULL)
    >>> Y ~ A:B
    >> 
    >>> This is in part because model.frame()'s output has class
    >>> "data.frame" instread of c("model.frame","data.frame"),
    >>> as SV4 did, so there are no methods for model.frames.
    >> 
    >>> Is there a reason that model.frame() returns a
    >>> data.frame with extra attributes but no special class or
    >>> is it just an oversight?
    >> 
    >> May guess is "oversight" || "well let's keep it simple"
    >> Do you (all readers) see situation where it could harm
    >> now (with the 20'000 packages on CRAN+BIoc+...) to do as
    >> SV4 (S version 4) has been doing?
    >> 
    >> I'd be sympathetic to class()ing it.  Martin
    >> 
    >>> Bill Dunlap TIBCO Software wdunlap tibco.com
    >> 
    >> ______________________________________________
    >> R-devel at r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] formula(model.frame(..)) is misleading
Martin Maechler