similar to: S4 structure classes and Ops methods

The current version of the methods package now has a namespace. Packages using S4 methods and classes can have NAMESPACE files. New directives can be included in NAMESPACE files to import and export classes and methods. Namespaces allow cleaner definition of the API for packages, and are needed for future improvements to R. NOTE: This is a major revision. In principle, it should be back

I'm seeing weird issues in methods initialization, i.e. loading marrayClasses loads Biobase, and when explicitly done, as in library(Biobase) library(marrayClasses) is fine, but when Biobase is loaded via a require statement in marrayClasses' .First.Lib, I end up with: Warning message: In the method signature for function "coerce", class "exprSet" has no

> R.version.string [1] "R Under development (unstable) (2012-02-26 r58493)" In the recent addition "It is important if you export S4 methods that the corresponding generics are available: the requirementa on this are stricter as from R 2.15.0. You may for example need to import plot from graphics to make visible a function to be converted into its implicit generic. But it is

Hello. Suppose you define a new S4-class, say > setClass("track", representation(x="numeric", y="numeric")) Don't worry if you have a deja vu, it's from the help page. Your new class is said to have a fixed structure: two slots, x, and y, and that should apply to all objects you construct as members of that class. > tr <- new( "track" )

>>>>> "JMC" == John Chambers <jmc at r-project.org> >>>>> on Tue, 28 Oct 2008 11:50:38 -0400 writes: JMC> The asymmetry is just the symptom of a more fundamental JMC> issue: There are no operator methods currently defined JMC> for "vector" classes, either combined with each other JMC> or with a non-S4 object.

Some changes to the implementation of S4 classes in the methods package will be committed to the r-devel version, probably later today. They should be largely back-compatible (exception noted below) but they are fairly extensive, so this is an advance notice. The changes form the first of a two-stage change aimed at making the implementation more consistent with R semantics, in particular with

1. I'm putting together my first package that uses S4 classes and objects. I'd like to document them, but I'm not sure what the documentation should look like, and package.skeleton doesn't produce any at all for the classes or methods. Are there any good examples to follow? 2. How do I do the equivalent of debug(foo), when foo is an anonymous function being used as a method?

In the little orientation data package I'm working on, the very first example fails, even though the same code works when used in a regular session. In my experience, this usually indicates T or F has been used instead of TRUE or FALSE, but that's not the case this time. The error message is > x <- eulerzyx(1,0,0) Error: Trying to get slot "validity" from an object of

One of the changes some packages are noticing from the recent modifications to methods is warnings of "undefined classes" during installation when the package extends S3 classes or uses them as slots UNLESSS they have been declared in a setOldClass() call. The green book "strongly recommends" declaring S3 classs this way (pp 449-451). The warnings on undeclared classes

Thanks to Duncan's recent work on SJava, I've got a (so far) stable platform to put together the R-Orca interface (dynamic graphics, including brushing, subseting, etc). While the first version will be looking at installation issues and study basic user interfaces for providing a few working examples, it will be important for this particular package to look at how one integrates a

Full_Name: Colin A. Smith Version: 1.8.0 OS: Mac OS X 10.2.6 Submission from: (NULL) (216.102.90.18) Both Biobase and my package annaffy use S4 classes to define methods for "[". Both packages use the save image method of installation. (See annaffy 1.0.3 in BioC CVS.) Depending on how both packages are loaded, the Biobase definitions seem to be getting masked out: >

I have some questions about S4 style methods and generics. First of all, is there any way of using default values for arguments in the generics/methods? My own experiments show that such arguments are always ignored. The green book seems to be silent on this matter. The second question is about using a non-trivial function body for generics. Page 351 of the green book gives an example of this

Might it be an idea to make "?" a special operator akin to "+" or "[", R users could then write their own help functions - may be even making "?" generic? With the proposed xml help system one could imagine quite sophisticated context sensitive help systems. Regards, John Marsland PS this has been a very useful debate for those of us enthusiastically

A revision of r-devel 2.4.0 is being committed today with changes to method and class management. The changes are internal but extensive. All packages that use S4 methods and classes need to be reinstalled from source to use the new version. The main effects are to speed up method caching and dispatch, and to fix some problems with selecting inherited methods. The new design is also

Hi, I have an S4 class directly derived from 'array' as shown in the code below (EBImage package of Bioconductor 2.1, devel), it simply contains array adding a couple of slots: setClass ("Image", representation (colormode="integer", filename="character", compression="character", resolution="numeric", features="list" ),

Does anyone know how to use the equivalent of debug() on an S4 method? I would like R to enter the browser not for the generic function, but for the method of the class that I specify. Thanks, David _____________________________ David Bickel http://davidbickel.com Research Scientist Pioneer Hi-Bred International Bioinformatics & Exploratory Research 7250 NW 62nd Ave., PO Box 552 Johnston,

Would we really need the special class or would simply checking the formals of the method against those of the generic be simple and fast enough? On Thu, Jan 29, 2015 at 9:41 AM, John Chambers <jmc at r-project.org> wrote: > I wouldn't want to add more to the current approach; if someone would like > to devote some time, the much preferable idea IMO would be to replace the >

Hi, I encounter a problem with method dispatch with S4 classes, using the 'sealed' parameter in setClass. See that example below: setClass("X",representation(x="numeric"),sealed=TRUE) setGeneric("foo",function(x) standardGeneric("foo")) setMethod("foo",signature("X"),function(x) print("foo(X)")) x <-

I'm sure that many people are in the same position as me in that they are trying to write packages and code that is vaguely "future proof". Would it be possible to get some guidance on how the R-core team see the evolution of the "base" package with regard to s4 methods. There seem to be quite a lot of inconsistencies between s3 and s4 methods and classes currently and

I wish it didn't have to depend on the name '.local'. Back when I wrote a lot of S4 methods I avoided the auto-generated .local and named the local function something that made sense so that is was easier for a user to track down the source of an error. E.g., define the generic QQQ with numeric and integer methods: setGeneric("QQQ", function(x, ...)NULL)