s4 methods and base

There is no inheritance in the S3 sense when an object contains an
object of another class. Am I missing something? Are you using this term
loosely or is there necessarily inheritance in S4 when one object
contains another object?

The basic point is that ordinary formal classes have to have an
unambiguous "structure"; that is, known slots each having a known class.

So the S3 class can't be extended by an S4 class, since the latter
wouldn't then have a known structure.

The other direction is technically feasible, but it feels like a bad
idea in general.

I can see that it feels bad, but it seems like the only way to do a
partial conversion. My problem is that it is much easier to do a big
project in small bites.

Also, would you suggest converting to namespaces before or after
converting to S4 classes?

At the moment, they don't work together, so it really amounts to
choosing which matters most to a given project.

The hope is to make them work together for 1.8, but that's still a hope
rather than a certainty.

With S4 classes, every object has a single class, with an explicit
definition.  That class can have superclasses  (defined as the classes
this class contains).

(newbie question) Are you using "contains" as a synonym for "extends,"

Yes, roughly.

meaning that many classes can contain the same superclass, or is this
intending to indicate that the logic is the reverse of (my understanding
of) S3 logic?

The S language terminology "Class B extends class A" is analogous to
"Class A is a superclass of class B" in other languages.  Saying "Class
B contains class A" is a special form of "extends" (the most common
one), where B has all the slots of A, and perhaps others as well.  The
setIs() function allows a more general version of "extends" that doesn't
depend on the data structures being compatible.

Now if I understand this correctly, and to be pedantic, one would say an
object of class B contains and object of class A, and,  the definition
of class B extends the definition of class A. Or, said differently,  a
class A object is a subset of a class B object, and a class A definition
is a superclass of a class B definition. Does that make sense?

- classes that don't have multiple strings in the class attribute can
often just be converted to a non-virtual S4 class, so long as objects
always have the same attributes.  Attributes go into slots (the slot
must have some specified class, but there are ways to allow some
variation in the actual type of data in the slot).

(newbie question) I often use attributes to stick "extra" information on
an object, like the date of retrieval from a database onto a matrix. If
the matrix is an S4 matrix class, does this mean that I have to define a
new class in S4 that extends the matrix class in order to stick on extra
information?

A good question, which points out some of the tradeoffs involved.  Yes,
if you want to work in terms of ordinary formal classes, the set of
slots (the "structure") is determined by the class, not by the
individual object.

It's fundamental to most formal class systems that objects from a class
have a known structure, in our case meaning that the slots are fixed as
to name and class.  This is indeed more restrictive than the traditional
S approach (dating back well before "white book" classes) of attaching
attributes, on a per-object basis, while retaining the underlying
"structure" (a matrix, as in your example).

It's a basic difference, and the formality has been adopted in many
languages because it makes possible operations that a less formal system
can't do, especially in terms of automating some computations.  Two
examples:  an object can be tested for being a valid member of a class;
and methods can be generated automatically to coerce an object to a
superclass, or to replace the part of an object that corresponds to a
superclass.

There are of course ways to add general annotation to a class, e.g., by
having a slot for miscellany (that slot might be a named list).

Would there be a point in formalizing this so that everyone does not
need to define extensions of all the basic classes with an extra
miscellany slot. I'm sure this sounds like herecy, but the alterative is
that many people will be doing somewhat similar things using different
class and slot names, and there will be a lot of unnecessary
incompatibility among packages.

Thanks again,
Paul

Regards,
John

Thanks,
Paul Gilbert