similar to: How to write (complex) coercion methods or "what's the reason to limit 'setAs()' the way it is limited"?

I'm trying to resolve a small problem that has arisen from introducing a NAMESPACE for the package SparseM. Prior to the namespace I had a class "matrix.diag.csr" that consisted of diagonal sparse matrices. It was defined to have the same attributes as the matrix.csr class and setAs was used to define how to coerce integers and vectors into this form:

Hi list, I've got a class B that contains a slot obj of class A. I'd like to be able to call all the methods of class A directly on objects of class B as if I had called the method on slot obj. This without overloading all methods of class A to work on class B. I don't define B as an extension of A, because I want class B to also work with objects of classes that inherit from

Hi, I am looking into a way to hook into the R coercion framework to allow me to convert table-like data stored within a COM object into a data.frame. Some of our COM objects have their own table-like data storage, and from R's point of view it's an object (EXTPTRSXP) decoarated with a sepcial symbol so we can easily identify it. COM_Table <- a_method_that_creates_the_object()

Dear list, I wonder how to write methods for the function 'as' in the sense that I can call 'as(object, Class, strict=TRUE, ext)' and let method dispatch figure out the correct method. AFAIU, there is a difference between, e.g. 'as.data.frame' and the methods of 'as()' as stated above since the former depends on arg 'x' instead of 'object',

Andreas, As far as I can tell (/conjecture), this is because the list of classes a particular class inherits from directly is appended to as needed, and so the order that a class extends others isd refined by the order that those connections are defined. We can see this with two setClassUnion calls, rather than required setAs: > setClass("grandma", slots = c(a =

Consider this: $ cat test.dat 1 a 2 b Now, we want to read the 2nd column as a factor and ignore the first (since it's just a sequential ID). We can't just put "factor" among the colClasses (would have been nice), so let's try this instead > setAs("character","factor",as.factor) Arguments in definition changed from (x) to (from) >

Dear colleagues, there is a behaviour with S4 (virtual) classes that I find very hard to understand: Depending on the position of setAs(), the tree of inheritance changes. This is my baseline example that defines the classes "grandma", "mother", "daughter" and a virtual class "mr_x". For a new instance if "daughter", "mr_x" is betweeen

Dear list, I hope this is the right place to post a feature request. If there's exists a more formal channel (e.g. as for bug reports), I'd appreciate a pointer. I work a lot with named nested lists with arbitrary degrees of "nestedness". In order to retrieve the names and/or values of "bottom layer/bottom tier", I love the functionality of 'unlist()', or

I ran into a problem recently trying to update a package which uses S4 methods using a recent beta of R. I think I can reproduce it with a simple example. I have package called `testpkg' in directory testpkg/. In the R/ subdirectory of testpkg/ I have a file called testpkg.R which contains the following two lines: setClass("testpkg", representation(pts = "list"))

Dear list, a while ago I posted this at r-devel but got no answers. Hope it?s okay to give it a shot again by cross-posting it here. TIA for any comments, Janko Von: Janko Thyson [mailto:janko.thyson.rstuff at googlemail.com] Gesendet: Montag, 21. Februar 2011 00:58 An: r-devel at r-project. org (r-devel at r-project.org) Betreff: Reference classes: error with missing arguments in method calls

Hi the list I am fighting with the twins setAs and setIs... Here are some questions and comments (comments to myself but that migth be wrong, it is why I am posting them) 1. Very surprising : using setIs define 'is', 'as<-' but not 'as' ??? 2. Using setAs define 'as', 'as<-' but not 'is'... What surprise me is that as<- can be define by

Dear R core team Please apologize for posting the same question twice on R-help and R-devel. Since I was not sure which list is appropriate I tried R-help (Tue Mar 22), but got no answer. Now I do not know if the formulation of my question was unclear or the question is not so easy to answer or to easy (what I do not hope). My problem: I create a new S4 class, containing one slot, data (of

I think I understand what you're saying now, but I'm still kind of missing the benefit from the approach. As far as I can tell just giving foo formals for the arguments you want it to catch gives you the end result you want, doesn't it? And if the generic has ... in it, you can (if you're very careful) add formals to specific methods that would capture arguments not meant for

Dear R gurus I've a question concerning the transformation of a new S4 class (that I defined) and the existing class "POSIXlt". I did the following: ## Definition of the new class: setClass("dtime", representation(data = "POSIXlt"), prototype(data = as.POSIXlt("2004/06/01"))) ## Transformation between the new class "dtime"

Well, the benefit lies in the ability to pass along arguments via `...` to more than one recipient that use *identical argument names* and/or when these recipients are not necessarily located on the same calling stack layer. I'm *not* after a *general* change in the way arguments are dispatched/functions are called as I'm actually a big friend of keepings things quite explicit (thus

Hi Gabriel, and thanks for answering. I'm basically just trying to find a way to use the power of `...` in more complex scenarios and I'm well aware that this might not be the best approach ;-) Regarding your actual question: "Are you suggesting methods be dispatched based on the *contents* of ... [...]?" Yes, I guess currently I kind of do - but not on the argument *names*

Janko, I'm not entirely sure I understand your proposal. Are you suggesting methods be dispatched based on the *contents* of ... (ie which arguments are in there)? This seems like it would be pretty different from how dispatch behaves now, which is entirely class based. Even the dispatching based on ... via dots methods is class based, having nothing to do AFAIK with the argument names. From

An example sent by Ross Ihaka points out a non-obvious step needed to export the results of setAs(). The as() mechanism can't use ordinary method dispatch because the second argument is the name of a class, not an object from the class. So it uses a "helper" function, coerce(), and sets methods for that function. Therefore, if you want to export the results of setAs(), at the

By reading the documentation for _setIs_ I noted that for the same object three different names are used. 1) the name of the first argument in the functions coerce and replace in setIs must be _obj_ (see example section or) setIs("MVCa","list",coerce=function(obj){obj@list},replace=function(obj,value){obj@list<-value}) 2) At the same time in the usage section:

I am extending a DBI connection by setClass("TSPostgreSQLConnection", contains=c("PostgreSQLConnection","TSdbOptions")) but the first time I use this I am getting a warning when it tries to coerce the TSPostgreSQLConnection to a PostgreSQLConnection. After the first use the warning stops, but the first warning is causing me problems when I do automatic checks