From jmc@research.bell-labs.com  Tue Jul  2 22:28:34 2002
From: jmc@research.bell-labs.com (John Chambers)
Date: Tue, 02 Jul 2002 17:28:34 -0400
Subject: Changes to the methods package
Message-ID: <3D221B02.C5B6CC13@research.bell-labs.com>

A new version was checked in to r-devel today.  These are the main
changes:

1.  Objects from the methods package are no longer copied into base.  As
a result, the behavior of data.class and all.equal should be the same
whether methods are attached or not.  (The methods package no longer
uses data.class.)  Also, detaching the methods package should restore
the behavior of class() to the S3 version.

The change should fix the bugs reported on these two topics.

The downside (perhaps) of the change is that class() and data.class()
will now occasionally be inconsistent when methods is attached. 
class(1:1) is "integer", but data.class(1:1) is "numeric".

2.  The representation of classes is now via an actual class,
"classRepresentation".  The metadata objects for class definitions are
objects from this class.  (Before, the class representation was a
special-purpose hack, partly to avoid bootstrapping problems.)

*** This means that packages using methods need to be installed from
source to make their metadata objects correct.  ****

The change repairs an inconsistency with the green book description
(section 7.6 in particular).

Also, the changes are a step on the way to making classes, like generic
functions, belong to a particular package.  Evenutually one should be
able to deal with the same class name on different packages to refer to
different classes.

3.  Metadata objects have been introduced to represent inheritance
information (both "superclass" extensions and "subclass" relations). 
Subclass information is now maintained in the cached class definitions 
(it's needed to maintain consistency when class relations change).

At the same time, the "extends" relation has been refined, to introduce
the notion of "simple" extensions.

A class extends another in a simple form if either: a) one class
contains another, in the setClass definition; or b) a class extends a
virtual class by a simple setIs declaration.

In the new form, objects can be supplied in certain situations from a
class that is a simple extension of the target class, with no change in
the actual object.  In particular, slots can be assigned without losing
their original class.

The idea here is very similar to the extension previously made to the
API that allowed extending classes to be used as arguments in method
dispatch, without the objects being altered.

There is some discussion of simple extensions and the rationale on the
developer's web page, at
http://developer.r-project.org/simpleExtension.html

-- 
John M. Chambers                  jmc@bell-labs.com
Bell Labs, Lucent Technologies    office: (908)582-2681
700 Mountain Avenue, Room 2C-282  fax:    (908)582-3340
Murray Hill, NJ  07974            web: http://www.cs.bell-labs.com/~jmc
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._


Changes to the methods package
John Chambers