810341
>
>> I get a list whereas if Pi is an ordinary matrix I get a
>> vector. Is this intentional?
>
> Well, no. But it has been "unavoidable" in the sense that it had not
> been possible to provide S4 methods for '...' in the "remote"
> pa
p fails, and we end up
> caching the wrong inheritance information.
>
> Thanks,
> Kevin
>
> On Sun, Jul 31, 2016 at 5:12 AM, John Chambers <j...@r-project.org> wrote:
>> (Just returning from the "wilds" of Canada, so not able to comment on the
>> speci
[1] TRUE
>>> "package:digest" %in% search()
>>[1] FALSE
>
>> This may be intentional, but the behavior seems surprising
>> and could be responsible for the behavior outlined
>> earlier.
>
> Yes, the behavior you outlined earlier is buggy, and
The Wikipedia statement may be a bit misleading.
S was never open source. Source versions would only have been available with a
nondisclosure agreement, and relatively few copies would have been distributed
in source. There was a small but valuable "beta test" network, mainly
university
class(x)
> [1] "integer"
>
> My wish for 2016: that selectMethod() always tells the truth. For
> example selectMethod("coerce", c("integer", "numeric")) doesn't
> in a fresh session, only after you call as(1L, "numeric")). Fu
class(x)
> [1] "integer"
>
> My wish for 2016: that selectMethod() always tells the truth. For
> example selectMethod("coerce", c("integer", "numeric")) doesn't
> in a fresh session, only after you call as(1L, "numeric")). Fu
3:32 AM, Martin Maechler <maech...@stat.math.ethz.ch> wrote:
>>>>>> Martin Maechler <maech...@stat.math.ethz.ch>
>>>>>>on Sat, 12 Dec 2015 10:32:51 +0100 writes:
>
>>>>>> John Chambers <j...@r-project.org>
>
"numeric" as a virtual class and "double" as a type/class.)
On Dec 11, 2015, at 1:25 AM, Martin Maechler <maech...@stat.math.ethz.ch> wrote:
>>>>>> Martin Maechler <maech...@stat.math.ethz.ch>
>>>>>>on Tue, 8 Dec 2015 15:25:21 +010
"numeric" as a virtual class and "double" as a type/class.)
On Dec 11, 2015, at 1:25 AM, Martin Maechler <maech...@stat.math.ethz.ch> wrote:
>>>>>> Martin Maechler <maech...@stat.math.ethz.ch>
>>>>>>on Tue, 8 Dec 2015 15:25:21 +010
We do need an explicit method here, I think.
The issue is that as() uses methods for the generic function coerce() but
cannot use inheritance in the usual way (if it did, you would be immediately
back with no change, since "integer" inherits from "numeric").
Copying in the general method for
I understand Hadley's point; it's a consequence of the modification of the
environment of the ref. class methods.
Good point, but it seems we can make that an option (there are advantages to it
of code quality and ease of writing, when it works);
Let's discuss possibilities, off-list until
cautious and more helpful for
detecting programming errors.
OTOH, John Chambers, the father of S and hence grandfather of R,
may have had good reasons why it seemed more logical to silently
ignore such out of bound negative indices:
One could argue that
x[-5] means leave away the 5-th
to
be locked, if it's not the package currently being loaded. Copying the
definition in order to update subclass information seems the only reasonable
choice, and no warning message is needed.
A revised version will omit this message.
On Mar 13, 2015, at 9:32 AM, John Chambers j...@r
This warning message is on my to-look-at list; I agree that sometimes it's
obviously possible for the system to get the information if it tries hard
enough.
The message means what it says: Class information in a session includes the
currently loaded subclasses of a particular class. Not
Lawrence lawrence.mich...@gene.com wrote:
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 j...@r-project.org wrote:
I wouldn't want to add more
On Jan 28, 2015, at 6:37 PM, Michael Lawrence lawrence.mich...@gene.com wrote:
At this point I would just due:
formals(body(method)[[2L]])
At some point we need to figure out what to do with this .local() confusion.
Agreed, definitely. The current hack is to avoid re-matching arguments
Roger,
Are you implying that your current code works differently under R-devel than
with the current release? Nothing I'm aware of would suggest that.
With or without setGeneric() (in either version but the single-argument is
cleaner), a generic function for image() is created in your
On 5/7/14, 5:21 AM, Therneau, Terry M., Ph.D. wrote:
Hadley asked about the Blue book; my shelf still has the earlier brown book
Becker and Chambers, 1984, S: An interactive environment for data
analysis and graphics.
Historically interesting, but there was never a guarantee that Version 3
I'm sympathetic to the problem. But, whatever my opinion, it's not likely that
the basic R paradigm with respect to S3/S4 methods will change much, and
certainly not for a year.
Meanwhile, let's remember the essential idea. Every function has a
corresponding implicit generic form (well,
I haven't looked at this in detail, but my guess is the following is the
distinction:
A simple call setGeneric(sort) makes a generic of the existing
function _with the existing package_:
setGeneric(sort)
[1] sort
sort
standardGeneric for sort defined from package base
function (x,
On Jan 3, 2014, at 9:46 AM, Hadley Wickham h.wick...@gmail.com wrote:
On Thu, Jan 2, 2014 at 7:16 PM, Henrik Bengtsson h...@biostat.ucsf.edu
wrote:
Does it make sense to talk about the class of the output of
substitute(...)? I'm puzzled by the following outputs:
ee - list(
A =
Previously reported and fixed in 3.0.2-patched (Bug 15481). Unless there is a
3.0.3, you will have to wait for 3.1.0.
On Dec 19, 2013, at 10:19 AM, Winston Chang winstoncha...@gmail.com wrote:
I've been seeing warnings when unloading packages. They can be seen with
the shiny and sp packages,
This was previously reported and fixed. See the NEWS file and bug
report 15481.
On 10/29/13 9:19 AM, Karl Forner wrote:
Dear all,
Consider this code:
library(data.table)
unloadNamespace('data.table')
It produces some warnings
Warning in FUN(X[[1L]], ...) :
Created a package name,
One additional point to Michael's summary:
The methods package itself should stay in Depends:, to be safe.
There are a number of function calls to the methods package that may be
included in generated methods for user classes. These have not been revised to
work when the methods package is
methods in Depends.
Or at least, import the package rather than just the obvious functions.
John
On Oct 25, 2013, at 3:46 PM, Paul Gilbert pgilbert...@gmail.com wrote:
On 13-10-25 05:21 PM, Henrik Bengtsson wrote:
On Fri, Oct 25, 2013 at 1:39 PM, John Chambers j...@r-project.org
wrote
Very good report.
Should be fixed in the development version for 3.1.0 and in 3.0.2 patched. (svn
revision 64076).
John
On Oct 18, 2013, at 8:51 AM, Karl Forner karl.for...@gmail.com wrote:
Hi all,
I have a problem with a package that imports two other packages which both
export a
The basic tool is setLoadActions(), which takes a function definition, with the
package's namespace as its argument. Read ?setLoadActions
There is no such thing as setLoadFunction, as far as the standard code in R.
While you haven't defined didn't work, an off-the-top-of-the-head idea would
Don't use .onLoad() to set class (or other nontrivial) information at load
time. Use setLoadActions(), which was created exactly to get around the
limitations of .onLoad().
For an example, see the Rcpp package, which uses this to set up load-time C++
linkages.
John Chambers
On Oct 3, 2013
And just in case anyone is curious about the history, return() with
multiple arguments was legal in S2 but the syntax in the blue book had
only return(expr), whether enforced or not in the code.
John
On 8/13/13 11:42 AM, luke-tier...@uiowa.edu wrote:
Both codetools and the compiler should
It's hard to see how repeated dispatch on the same classes can be that
slow, _if_ the function being called each time is itself doing some
substantial work.
The first call (in a session) with a particular signature searches for
inherited methods and stores the method found in a table. The
would also do the same to deal with union of unions.
Renaud
On 8 May 2013 19:02, John Chambers j...@r-project.org wrote:
No need for generic functions and methods. Just looking at the hierarchy of
the classes shows the problem.
With Martin's simplified version:
library(PkgA
No need for generic functions and methods. Just looking at the
hierarchy of the classes shows the problem.
With Martin's simplified version:
library(PkgA)
extends(A)
[1] A
library(PkgB)
extends(B)
[1] B A
setClassUnion(C, c(matrix, A))
extends(A)
[1] A C
extends(B)
[1] B A
So
This should now be fixed in r-devel and 3.0.0 Patched as of revision 62487.
On Mar 29, 2013, at 11:30 AM, John Chambers j...@r-project.org wrote:
Nothing to do with initFields. If you trace your redefined quote(), it's
called from the - assignment of x.
The x element in the environment
Thanks. No need for a complicated example actually:
C1 - setClass(C1, slots = c(x = numeric))
c1 - C1()
c1@x - Hello
validObject(c1)
Error in validObject(c1) :
invalid class C1 object: invalid object for slot x in class C1: got
class character, should be or extend class numeric
In
My guess is that the distinction here is between `@-` and `slot-`.
The first, but not the second, has been converted to a primitive (the second
has an optional argument, making it more of a nuisance to implement.)
Previously they did the same check; after the revision of `@-` they did not;
To respond a little more directly to what you seem to be asking for:
You would like an automatic conversion from your class (you don't give us its
name, let's call it frameHDF for now) and data.frame.
In R (and in OOP generally) this sounds like inheritance: you want a frameHDF
to be valid
and coefficients.
On Thu, Jan 3, 2013 at 1:08 PM, John Chambers j...@r-project.org wrote:
Martin Morgan commented in email to me that a change to any slot of an
object that has other, large slot(s) does substantial computation,
presumably from copying the whole object. Is there anything to be done
AM, John Chambers wrote:
Martin Morgan commented in email to me that a change to any slot of an
object that has other, large slot(s) does substantial computation,
presumably from copying the whole object. Is there anything to be done?
There are in fact two possible changes, one automatic
Martin Morgan commented in email to me that a change to any slot of an
object that has other, large slot(s) does substantial computation,
presumably from copying the whole object. Is there anything to be done?
There are in fact two possible changes, one automatic but only partial,
the other
Yes, you are right.
Mixing S3 and S4 methods for a generic is fine, although in subtle cases
one is safer promoting the S3 method to an S4 method, as you did in your
example.
Usually, the default method for the S4 generic is the S3 generic. But,
in general, it's not possible to check
should
remain as in rev. 61035.
John
On 10/30/12 2:09 PM, John Chambers wrote:
A heads up for those using Rcpp and perhaps other packages related to
reference classes.
The changes in 61035 cause a problem for classes defined with a slot
using the return value of setRefClass(), notably for Rcpp
if your
package does not install from the current r-devel until then.
John
On 10/27/12 2:07 PM, John Chambers wrote:
As of rev. 61035 in r-devel, setRefClass() now returns a generator
function, as setClass() has done since 2.15.0.
The convenient style is now:
mEdit - setRefClass(mEdit
As of rev. 61035 in r-devel, setRefClass() now returns a generator
function, as setClass() has done since 2.15.0.
The convenient style is now:
mEdit - setRefClass(mEdit,..)
xx - mEdit(data = xMat)
instead of
xx - mEdit$new(data = xMat)
The returned object still has fields and
On 10/18/12 6:31 AM, Martin Morgan wrote:
Initialization of this simple hierarchy
A = setClass(A, representation(x=numeric))
setClass(B, contains=c(VIRTUAL, A))
C = setClass(C, contains=B)
fails (neat that setClass returns generators; I hadn't realized that
before!)
Yes, from
The as() function does some non-standard stuff, and it appears in this
example to set up methods for coerce() in a way that fools the
disambiguation code (which is newer than the as() code, I think).
Pending a rewrite of as() (not imminent) the Note has been deactivated
for the coerce()
Good catch. This should have been fixed in r-devel, revision 60192. If
nothing bad results in other tests, we'll port it to the current patched
version.
Thanks,
John
On 8/5/12 4:31 PM, Martin Morgan wrote:
after this
setClass(A)
setGeneric(bar, function(x, y) standardGeneric(bar))
This doesn't seem to have anything to do with reference classes but
rather is deep in the evaluator. At least when set up in the simple
form of your example, the $- method is never called.
For example:
Foo - setRefClass(Foo)
foo - Foo$new()
find($-)
[1] package:base
debug(base::`$-`)
the fact that the call to dbGetQuery() was
generating the message. And caching the methods may be good for
performance, but when things change the second time you call them it
sure makes debugging difficult.
Best,
Paul
On 12-03-25 03:24 PM, John Chambers wrote:
On 3/24/12 5:43 PM, Paul Gilbert wrote
On 3/24/12 5:43 PM, Paul Gilbert wrote:
On 12-03-24 08:11 PM, John Chambers wrote:
On 3/24/12 1:29 PM, Paul Gilbert wrote:
(I think this is being caused by the new methods package in RC.)
Possibly, but the methods package isn't particularly new in its method
selection.
We need to see
On 3/24/12 1:29 PM, Paul Gilbert wrote:
(I think this is being caused by the new methods package in RC.)
Possibly, but the methods package isn't particularly new in its method
selection.
We need to see the definition of the class. The note implies that it
inherits from both
Thanks. Should be fixed in r-devel and 2.15 alpha from revision 58756.
(Nothing to do with trace() particularly. Low-level code to create
signature objects was not returning an S4 object.)
On 3/14/12 9:48 PM, Martin Morgan wrote:
With
R.version.string
[1] R version 2.15.0 alpha
(Can we please follow the terminology in the ?ReferenceClasses
documentation. Creativity is fine but here we need communication)
This has come up (once) before off-list. It could be made part of
reference classes via a general rewriting that would improve efficiency
as well. Not imminent,
On 1/24/12 9:35 AM, Prof Brian Ripley wrote:
On 24/01/2012 17:17, William Dunlap wrote:
Here is code that does make factor() work on a new
class like yours. It uses Sv3 methods.
Which is necessary as unique() is an S3 generic in the base namespace,
and creating some other function named
A relevant report, not just for VGAM but for maintainers of other
packages that define methods for functions that have both generic and
non-generic versions in other packages.
The problem is that VGAM Depends on stats4 but does not import from
it. So when VGAM is loaded, only the old version
requirements for check would not require
documenting implicit generics if there were corresponding exported
methods (of course, the package author is still responsible for
documenting the exported methods themselves).
John
On 12/22/11 10:01 AM, Martin Morgan wrote:
On 12/18/2011 11:04 AM, John Chambers
Thanks,
Michael
On Fri, Dec 16, 2011 at 4:52 PM, John Chambers j...@r-project.org
mailto:j...@r-project.org wrote:
The key point here is that setGeneric(unique) is done that way,
without other argument, whoever does it. That creates the generic
from the implicit generic corresponding
The subject heading is correct if referring to exportMethods() and
importMethodsFrom(). They refer to the methods tables, not the generic
functions, whatever the extensions manual says.
Looking into the code of namespaceImportMethods() will illustrate this.
It just deals with lists of
from importMethods() possible.
On 12/16/11 2:57 PM, Martin Morgan wrote:
On 12/16/2011 12:19 PM, John Chambers wrote:
The subject heading is correct if referring to exportMethods() and
importMethodsFrom(). They refer to the methods tables, not the generic
functions, whatever the extensions
Right, thanks for the catch. Actually, field names s, se, sel
would also produce the bug. Partial matching of argument names bites
again. This should be fixed in r-devel and 2.14 patched, as of SVN rev.
57842.
Do try to follow the API in the documentation and use generator objects
for
. And easier to discuss (e.g., section 9.3 of SoDA).
You're hardly the only sinner in the flock. I imagine many packages on
CRAN would have failed by now if there was a problem. I only complain
about it when feeling fussy.
John
.
On 09/18/2011 11:04 PM, John Chambers wrote:
The distinction
The distinction here is simple inheritance (Software for Data
Analysis, p. 346). Your first example is simple inheritance (would be
clearer if you used the contains= argument). In the second version you
supply an explicit coerce method, so method dispatch can no longer just
pass in the
There is also an item in the NEWS file:
Field assignments in reference classes are now consistent with
slots in S4 classes: the assigned value must come from the declared
class (if any) for the field or from a subclass.
On 8/5/11 7:24 AM, Simon Urbanek wrote:
It's worth actually reading
In R-devel, a recent change (Rev. 56572) makes assignments to fields in
reference classes consistent with assignments to slots in S4 classes,
when the field was declared with a class in the call to setRefClass().
The value assigned must come from the declared class for the field, if
any, or
, John Chambers wrote:
In principle, two separately developed packages could use
the same class name, and a user could then attach both
and attempt to use methods for both classes.
That has never worked, but some changes have been added
to r-devel to handle
exist, a utility findDuplicateClasses(details =
FALSE) will give the names of the duplicated classes. It's not yet
exported so you need to call methods:::findDuplicateClasses()
John
On 7/21/11 10:29 AM, John Chambers wrote:
In principle, two separately developed packages could use the same
class
In principle, two separately developed packages could use the same class
name, and a user could then attach both and attempt to use methods for
both classes.
That has never worked, but some changes have been added to r-devel to
handle this case. The changes involve extending the signature
I don't have anything to suggest on your specific example but perhaps
these two notes are relevant.
1. As is mentioned in the documentation, it's generally a bad idea to
write S4 initialize() methods for reference classes, rather than
reference class methods for $initialize():
a reference
in R-2.12.1 at the installation loading
check, but do not work when loading the package from an R session?
Could you please briefly give some explanations or pointers?
Thank you.
Bests,
Renaud
On 23/06/2011 18:44, John Chambers wrote:
The workaround is to use the package's namespace, as you did
The workaround is to use the package's namespace, as you did. That's
one of the reasons why pkgname is an argument to .onLoad().
Depending on what you want to do, you can either use the namespace as an
argument where= or get the class definition from the namespace and use
it in place of the
Good catch.
Here's the problem. To save space and time, reference methods are not
all copied to every object in the class. Instead, the methods are
copied in when first accessed. Methods are functions which use the
object as their environment. So that is the sense in which lazy
The bug should be fixed in r-devel and 2.13 patched, as of svn rev. 56090.
John
On 6/7/11 12:42 AM, Iago Mosqueira wrote:
On Mon, Jun 6, 2011 at 11:28 PM, John Chambersj...@r-project.org wrote:
This is a bug, medium-subtle, but also raises an interesting software design
point.
The Bug:
and implemented.
John
On 6/7/11 6:15 AM, luke-tier...@uiowa.edu wrote:
On Mon, 6 Jun 2011, John Chambers wrote:
This is a bug, medium-subtle, but also raises an interesting software
design point.
The Bug:
Nothing specific about ANY and missing, but the issue is whether
the method was inherited
and implemented.
John
On 6/7/11 6:15 AM, luke-tier...@uiowa.edu wrote:
On Mon, 6 Jun 2011, John Chambers wrote:
This is a bug, medium-subtle, but also raises an interesting software
design point.
The Bug:
Nothing specific about ANY and missing, but the issue is whether
the method was inherited
for addressing this!
Regards,
Janko
On 03.06.2011 19:13, John Chambers wrote:
Well, your mail is unclear as to what you expected, but there is one
bug shown by your example.
The behavior of S4 classes is sensible, at least as far as the example
shows:
setClass(A, representation(x=ANY))
[1
This is a bug, medium-subtle, but also raises an interesting software
design point.
The Bug:
Nothing specific about ANY and missing, but the issue is whether the
method was inherited (the ANY case) or defined directly (the missing
case).
Generic functions keep a cached table of dispatched
As it says on the help page ?ReferenceClasses:
All reference classes inherit from the class envRefClass
So,
is(x, envRefClass)
And, less well documented but less typing:
is(x, refClass)
also works.
On 6/6/11 9:48 AM, Janko Thyson wrote:
Dear list,
is there a shortcut-function to check
Well, your mail is unclear as to what you expected, but there is one bug
shown by your example.
The behavior of S4 classes is sensible, at least as far as the example
shows:
setClass(A, representation(x=ANY))
[1] A
setClass(B, contains=A, representation(x=character))
[1] B
new(B, x=1:3)
Right, but Michael's point is valid. It's the standard bug from having
to explicitly check for a non-empty list before taking names(x).
Will fix. Thanks for the catch.
John
On 6/1/11 9:21 AM, William Dunlap wrote:
-Original Message-
From: r-devel-boun...@r-project.org
Known Subclasses: listOfMethods
xx - new(namedList, list(a=1,b=2))
names(xx)
[1] a b
names(xx) - c(D, E)
xx@names
[1] D E
There was no question of breaking inheritance.
On 5/16/11 4:13 PM, Hervé Pagès wrote:
On 11-05-16 01:53 PM, John Chambers wrote:
On 5/16/11 10:09 AM, Hervé Pagès
On 5/17/11 9:53 AM, Hervé Pagès wrote:
On 11-05-17 09:04 AM, John Chambers wrote:
One point that may have been unclear, though it's surprising if so. The
discussion was about assigning names to S4 objects from classes that do
NOT have a formal names slot. Of course, having a names slot
d e
names(b)
[1] a b c d e
This allows both the S4 and the primitive code to deal with a
well-defined object.
John
On 5/15/11 3:02 PM, Hervé Pagès wrote:
On 11-05-15 11:33 AM, John Chambers wrote:
This is basically a case of a user error that is not being caught:
Sure!
https
On 5/16/11 10:09 AM, Hervé Pagès wrote:
On 11-05-16 09:36 AM, John Chambers wrote:
You set up a names slot in a non-vector. Maybe that should be allowed,
maybe not. But in any case I would not expect the names() primitive to
find it, because your object has a non-vector type (S4
This is basically a case of a user error that is not being caught:
On 5/14/11 3:47 PM, Hervé Pagès wrote:
Hi,
I was stumped by this. The two S4 objects below looked exactly the same:
a1
An object of class A
Slot aa:
integer(0)
a2
An object of class A
Slot aa:
integer(0)
str(a1)
Formal
Good suggestion for this case.
But the general problem is tricky. What about reference objects
contained in attributes or slots of other objects, etc? What is needed
for total copying is a switch in the low-level duplication code that
says to copy reference objects. It's also possible
,
John Chambers
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
On 5/3/11 2:39 PM, Hadley Wickham wrote:
Part of the motivation for the reference classes was to bring a general OOP
view to R. One can start from some essential concepts of objects and their
properties, inheritance and class definition, as have evolved over a very
long time.
Next, there is a
Interesting idea.
One approach would be to test against the _environment_ of the prototype
object in the class definition. Since the initialize method for a
reference class must call new.env(), one knows that a real object from
the class has a different environment. Using that fact one
On 5/4/11 9:24 AM, Hadley Wickham wrote:
Are you familiar with Concepts, Techniques, and Models of Computer
Programming by van Roy and Haridi? That's what really helped me to
understand the strengths and weaknesses of the various styles of
programming.
Thanks, I wasn't. Yes, interesting
It makes no sense to replace the .self field: that field is initialized
to be a reference to the object. If you change it, it's no longer that
reference.
There are many things wrong with your example, so it's better to take a
very simple version:
mkTest - setRefClass(test,fields = list(a
Yes, as presented on that site it makes a little more sense:
While experimenting with the new reference classes in R I noticed some
odd behaviour if you use the [[ ]] notation for methods
(X[[doSomething]] instead of X$doSomething). This notation works for
fields, but I initially thought it
On 5/1/11 3:37 PM, Martin Morgan wrote:
On 05/01/2011 03:09 PM, John Chambers wrote:
Yes, as presented on that site it makes a little more sense:
While experimenting with the new reference classes in R I noticed some
odd behaviour if you use the [[ ]] notation for methods
(X[[doSomething
You're confusing functional and OOP-style methods.
Since you define an OOP-style method, you need to invoke it in OOP style.
With your example:
tmp$`[`(random)
[1] -1.439131143 -0.630354726 0.822006263 -0.651707539 0.475332681
[6] 0.002680224 1.539035675 -0.117609566 2.066227300
The warning is there because all is not just fine, in general and in
particular not in your example.
If a superclass is not virtual, the prototype object for the new class
must have a member of that class in the appropriate slot. How could it
do so in this case? As a result, your class will
This is a good wish-list item. The natural mechanism would be a version
of the standard trace() function as a reference method with the same
arguments as the current trace(), minus those that make no sense. So:
xx$trace(edit, browser)
for example, to trace execution of the reference method
Good to know. However, _please_ don't use the horrible kludge in the
attr(..) expression. From my experimenting, it worked fine just to say:
mtrace(edit, from = xx)
and even if that did not work, from = as.environment(xx) is identical in
effect to the attr() expression and means something.
Look at ?ReferenceClasses for this OOP paradigm in R, which is quite
different from the functional paradigm of S4 methods.
On 4/6/11 7:54 AM, A Zege wrote:
Apologies for asking something that is probably very obvious, i just started
with S4 classes and i guess i am not finding documentation
There is a virtual class refClass that all reference classes subclass,
so is(x, refClass) is the natural test, as in:
foo - setRefClass(foo, fields = bar)
x - foo$new()
is(x, refClass)
[1] TRUE
On 3/10/11 7:40 AM, Jeffrey Horner wrote:
Hi all,
I've constructed the following function to
The names slot is not part of the basic vector types/classes.
If you want to extend named lists, extend the class namedList:
getClass(namedList)
Class namedList [package methods]
Slots:
Name: .Data names
Class: list character
Extends:
Class list, from data part
Class vector,
No worries, and we will get rid of the warning message.
Certain of the S4 classes require methods for particular primitive
functions. If a subclass of one of those classes is loaded from a
package, then we need to turn on method dispatch for the corresponding
primitive(s). For efficiency,
PS: this is another glitch that arises when you don't use NAMESPACE
files. If the .requireCachedGenerics is in a NAMESPACE and not
exported, the conflict does not arise.
On 2/15/11 12:52 PM, John Chambers wrote:
No worries, and we will get rid of the warning message.
Certain of the S4
1 - 100 of 274 matches
Mail list logo
