341
>
>> 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"
> past, w
p fails, and we end up
> caching the wrong inheritance information.
>
> Thanks,
> Kevin
>
> On Sun, Jul 31, 2016 at 5:12 AM, John Chambers wrote:
>> (Just returning from the "wilds" of Canada, so not able to comment on the
>> specifics, but ...)
>>
>>
ot; %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 I also have
> seen similar bugous beh
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 stati
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")). Full
> story here
e to go with
that (on r-devel), advertising that it may change the effective definition of
some classes.
But I can sympathize with choosing 1, 2 or neither.
John
PS: Until Jan. 4, I may be even poorer at replying than usual, while getting
the current book off to the publisher.
On Dec 19, 201
"numeric" as a virtual class and "double" as a type/class.)
On Dec 11, 2015, at 1:25 AM, Martin Maechler wrote:
>>>>>> Martin Maechler
>>>>>>on Tue, 8 Dec 2015 15:25:21 +0100 writes:
>
>>>>>> John Chambers
>
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 co
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 thin
entry
>
>
> r42123 | ihaka | 2007-07-05 02:00:05 +0200 (Thu, 05 Jul 2007) | 4 lines
>
> Changed the behaviour of out-of-bounds negative
> subscripts to match that of S. Such values are
> now ignored rather 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 wrote:
&
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 criti
Lawrence 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 wrote:
>
>> I wouldn't want to add more to the current
of searching for an assignment to '.local' you could
> search for an assignment to the name of the function used in the last
> function call of the method.
>
>
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
> On Thu, Jan 29, 2015 at 6:34 AM, Hadl
On Jan 28, 2015, at 6:37 PM, Michael Lawrence 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 on
method dispatch,
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 package'
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, parti
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
On Jan 3, 2014, at 9:46 AM, Hadley Wickham wrote:
> On Thu, Jan 2, 2014 at 7:16 PM, Henrik Bengtsson
> 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 = substitute( a <- 1 ),
>> B = subst
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 wrote:
> I've been seeing warnings when unloading packages. They can be seen with
> the shiny and sp packages, among others (this is
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, ‘201
is to put 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 wrote:
>
>
> On 13-10-25 05:21 PM, Henrik Bengtsson wrote:
>> On Fri, Oct 25, 2013 at 1:39 PM, John Chambers
>> wro
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 n
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 wrote:
> Hi all,
>
> I have a problem with a package that imports two other packages which both
> export a method for the `[` prim
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,
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 fol
This is a useful observation. To talk about it, though, we need to re-express
it in terms that make sense for R; there are too many misconceptions otherwise.
The basic observation is this: When simple subset or element replacement is
done in a loop, normally the object is only copied on the fi
n class1 could be used, reset by any
> subsequent call to setClass(class1, ...) or removeClass(class1). I guess
> setClassUnion would also do the same to deal with union of unions.
>
> Renaud
>
>
> On 8 May 2013 19:02, John Chambers wrote:
> No need for generic functions an
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"
> ext
No intended change. The trace method was not updated when reference
class generators became functions. Should be fixed now in r-devel and
3.0.0 patched (rev 62699).
Thanks for the catch.
John
On 4/29/13 11:30 PM, Kohske Takahashi wrote:
Hi
The final line of the example in ?setRefClass ind
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 wrote:
> Nothing to do with initFields. If you trace your redefined quote(), it's
> called from the <<- assignment of x.
>
> The "x" e
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 for the reference class object is
implemented as an active binding in order to enforce the class when assigning
the field.
Effectively that makes th
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;
a
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 cla
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
rameters and coefficients.
On Thu, Jan 3, 2013 at 1:08 PM, 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
Back to the scenario in my email of Jan. 3: We have objects with some
large (or very large) components and some other components as well. We
need to modify the smaller stuff but are not changing the big data. How
can we avoid copying the big data?
(A use case might be some modeling of large
mport phase of installation.
John
On 1/3/13 11:08 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?
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 r
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 algori
ce methods 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(), notabl
27;t panic 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 <- setRe
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 me
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!)
Ye
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() generi
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("ba
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:
There have been several threads on this list about the Notes generated
in the check process regarding "global variables" with no visible
definition. These can be useful but false positives tend to obscure
valid notes.
The function globalVariables() has been added to the utils package, in
the
Thanks, Michael.
It looks good. I committed it to r-devel (rev 58925).
If nothing bad happens, we can merge it into 2.15.0 patched. (Nothing I
found in CRAN seems to test complicated importMethodsFrom usage.)
John
On 4/5/12 3:35 PM, Michael Lawrence wrote:
Hi,
I've noticed an issue with
;MySQLDriver", dbname="character"),
definition=function(drv, dbname, ...) {
con <- dbConnect(drv, dbname=dbname, ...)
new("TSMySQLConnection" , con, drv="MySQL", dbname=dbname,
hasVintages=FALSE,
hasPanels =FALSE)
})
I no longer get the note. I am restarting R ea
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.
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 "MySQLConnect
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 (201
Bug. Should be fixed (rev 58642) in r-devel and R 2.15.0 alpha.
Thanks.
On 3/7/12 3:30 PM, Hervé Pagès wrote:
Hi,
I wonder if this is a feature or a bug:
> isGeneric("&&")
Error in genericForPrimitive(f) :
methods may not be defined for primitive function ‘&&’ in this
version of R
>
(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, b
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 'un
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 versio
ted generic also carried with
it the burden of documenting the generic (again).
Even with the insights from this thread, I find myself spending a very
long time working out the appropriate NAMESPACE declarations for my
current projects.
Martin
John
Thanks,
Michael
On Fri, Dec 16, 2011 at 4:5
e). Otherwise, we're adding
inconsistent requirements for primitives vs true functions in the base
package.
John
Thanks,
Michael
On Fri, Dec 16, 2011 at 4:52 PM, John Chambers mailto:j...@r-project.org>> wrote:
The key point here is that setGeneric("unique"
7;s what would make an automatic imputation of the generic
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,
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 metho
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
fo
r
empty name fields. 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 Chamber
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 o
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 fr
On 7/25/11 12:07 AM, Martin Maechler wrote:
John Chambers
on Sun, 24 Jul 2011 14:58:23 -0700 writes:
> A point that has come up a couple of times with the new
> test is that two classes from two packages may be "the
> same class". Should that turn o
cate classes do 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 package
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" c
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 m
nd when the installation sources
the script prepare the package for lazy loading.
- why things seemed to work ok 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,
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 c
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
evaluati
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 Chambers wrote:
This is a bug, medium-subtle, but also raises an interesting software design
point.
The Bug:
Nothing specific
em to have been
encountered before your example. We won't add the warning in the
immediate future, and as Luke pointed out, even Dylan just advises.
This may be more a matter for a "code tools" approach. So not to worry
just yet!
John
Iago
On Tue, Jun 7, 2011 at 7:06 PM, Joh
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 wh
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 c
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 disp
tation(x="character"))
[1] "B"
> new("B", x = "abc")
An object of class "B"
Slot "x":
[1] "abc"
Thanks for addressing this!
Regards,
Janko
On 03.06.2011 19:13, John Chambers wrote:
Well, your mail is unclear as to wha
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"
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
[mailto:r-deve
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
character
Extends:
Class "list", from data part
Class "vector", by class "list", distance 2
Known Subclasses: "listOfMethods"
> xx <- new("namedList", list(a=1,b=2))
> names(xx)
[1] "a" "b"
> names(xx) <- c("D
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").
;character"), contains = "integer")
[1] "B"
> b <- new("B", 1:5)
> names(b) <- letters[1:5]
> b
An object of class "B"
[1] 1 2 3 4 5
Slot "names":
[1] "a" "b" "c" "d" "e"
> nam
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(a
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 that
that useful performance tools can be designed.
If you can provide us with examples that we can use and share, please
send a description to:
Justin Talbot
As examples accumulate, the plan is to make them available to the
community---details to be worked out.
Thanks in advance,
John Cha
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 = lis
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 sim
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 could
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 f
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
(
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
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 1.
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 wil
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.
1 - 100 of 304 matches
Mail list logo
