Paul Gilbert wrote: > > John > > > But maintainers of software using S3 methods and classes > > might want to consider conversions or partial conversions, when and if > > they decide to revise the software. > > I'm curious about the logistics of a partial conversion. Initially I > think I will avoid classes that inherit from other classes. But what > general approach would you suggest for classes that have an object of > another class in their structure. Can the larger object be an S4 class > and the contained object an S3 class, or would you start the other way > around, or is it not possible?
I would think it's wise to imagine converting all the functions in an S3 inheritance "tree" at the same time. 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. > > 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. > > > - 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). Regards, John > > Thanks, > Paul Gilbert > > ______________________________________________ > [EMAIL PROTECTED] mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel -- John M. Chambers [EMAIL PROTECTED] 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 ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
