On 14-03-02 08:05 PM, Simon Urbanek wrote:
> Ben,
>
> On Mar 2, 2014, at 7:38 PM, Ben Bolker wrote:
>
>> We (the lme4 authors) are having a problem with doing a proper
>> deep copy of a reference class object in recent versions of R-devel
>> with the LAZY_DUPLICATE_OK flag in src/main/bind.c ena
Ben,
On Mar 2, 2014, at 7:38 PM, Ben Bolker wrote:
> We (the lme4 authors) are having a problem with doing a proper deep
> copy of a reference class object in recent versions of R-devel with
> the LAZY_DUPLICATE_OK flag in src/main/bind.c enabled.
>
> Apologies in advance for any improper termi
We (the lme4 authors) are having a problem with doing a proper deep
copy of a reference class object in recent versions of R-devel with
the LAZY_DUPLICATE_OK flag in src/main/bind.c enabled.
Apologies in advance for any improper terminology.
TL;DR Is there an elegant way to force non-lazy/deep co
Hello All,
I posted this earlier on R-help but received no answers. This touches the
implementation of reference classes so maybe R-devel is a better place.
The memory consumption of reference classes seems to increase dramatically
(roughly 10x in the example below) with serialization/unserializ
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
Hello, I am working with a reference class:
Foo <- setRefClass("Bar",
fields = list( a = "numeric"),
methods = list( baz = function( xa ) a <<- xa )
)
x <- Foo$new()
x$baz(2)
x$a
y <- new("Bar")
y$baz(4)
y$a
But that might be confusing, since new(Foo) does not work and neither does
Bar$new()
Thanks for the answer! Sorry, must have missed that part of the help
page. Your second approach is exactly what I was looking for.
Regards,
Janko
On 06.06.2011 23:38, John Chambers wrote:
As it says on the help page ?ReferenceClasses:
All reference classes inherit from the class "envRefClass"
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
Dear list,
is there a shortcut-function to check whether a class is a Reference
Class or not? There's something like this for S4 classes
('isS4(object)'), but I couldn't find anything regarding Ref Classes.
Currently, I'm doing it this way, which is a bit clumsy:
A <- setRefClass("A", fields
Cool, thanks a lot for the insight! I forgot that there is the option to
use 'contains="VIRTUAL" and probably out of laziness usually set my
virtual S4 classes simply via 'setClass("Something")'.
On 27.05.2011 15:22, Martin Morgan wrote:
> On 05/27/2011 06:13 AM, Janko Thyson wrote:
>> Dear list
On 05/27/2011 06:13 AM, Janko Thyson wrote:
Dear list,
is it possible that method dispatch checks for superclasses/virtual
classes before checking "ANY"?
I'd like to build a generic initialization method for all my Reference
Class (say "MyDataFrame") objects by having them inherit from class, s
Dear list,
is it possible that method dispatch checks for superclasses/virtual
classes before checking "ANY"?
I'd like to build a generic initialization method for all my Reference
Class (say "MyDataFrame") objects by having them inherit from class, say
"MyRefClassVirtual" (which would have
Dear list,
I'm getting some strange behavior with Reference Classes every once in a
while and I can't really put my finger on the cause. It'd be great if
someone using Reference Classes could check if he/she experiences
similar problems:
The thing is that when I alter the definition of a Ref
Hi everyone,
just wanted to ask what's the smartest/recommended way of defining
getter and setter function *shortcuts* (i.e. something like "[", "[<-")
for Reference Class objects?
Or is it desired to not use this stuff, but define methods like
'obj$getSubset(row=1:3, col=1)' and 'obj$setSubse
Dear Hadley,
Thank you very much for your interest in the question proposed.
The Con class is a Reference Class. P and k are from class listCon.
I provide in the following lines a little more detail in order to be able
to reproduce the case.
#Class declaration
gCon <- setRefClass("Con", fields=l
Dear Hadley and John,
My main interest in the question was to understand what was happening.
Thank you very much for your clarifications and the piece of code.
Manuel
El 11/05/11 18:32, "John Chambers" escribió:
>Good suggestion for this case.
>
>But the general problem is tricky. What abou
> 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 one does NOT want all such
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
Hi Manuel,
The source code for copy is short and pretty readable, so I'd
encourage you to look at it:
> setRefClass("XXX")$copy
Class method definition for method copy()
function (shallow = FALSE)
{
def <- .refClassDef
value <- new(def)
vEnv <- as.environment(value)
selfEnv <- as.
2011/5/10 Manuel Castejón Limas :
> Dear all,
>
> I've just discovered the 'Reference Classes'.
> In a previous attempt ---a year ago--- to re-implement in a Object Oriented
> fashion the AMORE package using S4 classes I strongly felt the need of such
> capability. It's great to have the Reference
Dear all,
I've just discovered the 'Reference Classes'.
In a previous attempt ---a year ago--- to re-implement in a Object Oriented
fashion the AMORE package using S4 classes I strongly felt the need of such
capability. It's great to have the Reference Classes now available. Along
with the discove
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
Sorry guys,
but I chose a really stupid name before (no "reference classes").
Hope it's okay to re-post.
Cheers,
Janko
>>> ORIGINAL MESSAGE <<<
Dear list,
Is it possible to update or reassign '.self' with an image of '.self'
(e.g. a locally stored .Rda file) from within a method?
I know t
On Wed, May 4, 2011 at 11:35 AM, John Chambers wrote:
> 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 t
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
>> 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 similar distinction between func
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
> 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 fundamental choice of paradigm be
On Sun, 1 May 2011, Martin Morgan wrote:
On 05/01/2011 03:09 PM, John Chambers wrote:
It would be interesting to get some experience and opinions on whether
this is a good idea or not. It breaks encapsulation, in that the
behavior of the class can no longer be inferred from the class
definition
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"]]
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"]] instead of X$doSomething). This notation
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
If this message is garbled for anyone else, the original question on
stackoverflow is here:
http://stackoverflow.com/questions/5841339/using-notation-for-reference-class-methods
Hadley
On Sat, Apr 30, 2011 at 11:35 AM, Chad Goymer wrote:
>
> I've been trying to use methods for reference classes
I've been trying to use methods for reference classes via the notation
"[[...]]" (X[["doSomething"]] rather than X$doSomething), but it failed to
work. However, I did find that if you use the usual "$" notation first,
"[[...]]" can be used afterwards. The following simple example illustrates th
Dear list,
I'm having problems in understanding an error that pops up in the context of
missing arguments with methods of reference class objects.
Because of the following statement taken from '?referenceClass', my ref
class methods call explicit S4 methods:
"Reference methods should be ke
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 classe
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, th
Dear all,
If I load a package which creates reference classes whilst another
such package is also loaded, I get a warning about masking of the
".requireCachedGenerics" variable. (FWIW, both packages are
lazy-loaded.) Googling this variable name turned up only one previous
discussion, which didn't
"Janko Thyson" writes:
> Dear list,
>
> just to make sure that I understand 'unregistering' methods for S4 reference
> classes correctly:
>
> If I registered a method and want to 'unregister' (i.e. remove) this method
> again, objects/instance created of the respective class still feature the
> r
No reference class method explicitly does this, but it's a natural
utility. Some form of $copy() will be added. It needs a shallow/deep
option; i.e., if a field is itself a reference class object, should that
field be cloned as well. The full reflectance available should make a
single method
Dear list,
I don't know what's the correct term for this in the OOP context, but is it
possible to "clone"/copy an instance of a reference class (say 'a') so that
I get an *autonomous* second instance 'b'? Autonomous in the sense that
changes to 'a' do not affect 'b'.
I know that this is somewha
Dear list,
just to make sure that I understand 'unregistering' methods for S4 reference
classes correctly:
If I registered a method and want to 'unregister' (i.e. remove) this method
again, objects/instance created of the respective class still feature the
removed method until I do an explicit re
> -Ursprüngliche Nachricht-
> Von: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] Im Auftrag von John Chambers
> Gesendet: Montag, 22. November 2010 18:51
> An: r-devel@r-project.org
> Betreff: Re: [Rd] reference classes: quest
>>
>> What am I doing wrong here?
Not using a recent enough version of R probably (and not telling us what
version you are using).
The warning (not an error) should not appear in current r-devel or
2.12-patched. In other words, works fine for me.
John
On 11/21/10 3:40 PM, Janko Thyson wrot
Hmm, interesting: it's the virtual class that causes the trouble. If a
virtual class is a ref class, everything works fine. If it's a standard S4
class, it results in the error below.
Regards,
Janko
> -Ursprüngliche Nachricht-
> Von: Janko Thyson [mailto:janko.thy...@ku-eichstaett.de]
> G
Dear list,
I have a reference class which should act as a "generic" superclass for
other classes. I've read the respective section at ?setRefClass and put the
name of the superclass to the 'contains' argument of an example subclass
(see class defs below). Classnames are set in a way that shouldn't
Dear list,
I'm aware that this post does not really comply with the posting guide with
respect to "providing a minimal reproducible code example". But I do hope
it's okay that I spared uninterested readers by putting that into the
attachment ;-)
The thing is that I'm not really familiar with "tru
Thanks a lot for the comments! I'll give the serveral alternatives a try to
see if it gets me what I want.
Cheers,
Janko
> -Ursprüngliche Nachricht-
> Von: Vitalie S. [mailto:spinuvit.l...@gmail.com]
> Gesendet: Mittwoch, 17. November 2010 13:51
> An: Janko Thyson
> Cc: 'r-de...@r-projec
"Janko Thyson" writes:
> Hi there,
>
> I'd like to choose between an "static" and "dynamic" access of a reference
> class field, say 'a'.
>
> myObj <- getRefClass("Blabla")$new()
>
> Static: myObj$a
>
> Dynamic: myObj$a.get() where the function retrieves the data
> f
Le 17/11/10 13:07, Janko Thyson a écrit :
Hi there,
I'd like to choose between an "static" and "dynamic" access of a reference
class field, say 'a'.
myObj<- getRefClass("Blabla")$new()
Static: myObj$a
Dynamic: myObj$a.get() where the function retrieves the
Hi there,
I'd like to choose between an "static" and "dynamic" access of a reference
class field, say 'a'.
myObj <- getRefClass("Blabla")$new()
Static: myObj$a
Dynamic: myObj$a.get() where the function retrieves the data
from a database (or some other loca
John Chambers writes:
> Good diagnoses.
>
> This thread brought up a point or two that needed some fixes to the
> documentation and code. They should be in
> r-devel and 2.12 patched (from rev. 53471).
>
> Briefly:
>
> - Initialization methods should take account of future subclasses to your
>
Good diagnoses.
This thread brought up a point or two that needed some fixes to the
documentation and code. They should be in r-devel and 2.12 patched
(from rev. 53471).
Briefly:
- Initialization methods should take account of future subclasses to
your class by including and passing on the
?ReferenceClasses says "Reference methods can not themselves be
generic functions; if you want additional function-based method
dispatch, write a separate generic function and call that from the
method". So I think you'd need to take that approach in your
"initialize" method.
Hope this helps,
Jon
Thank you. Your example really clarifies what the $initialize(...)
function is supposed to do.
Do you know if there is a straightforward way to dispatch the $new(...)
method based on the signature of the arguments? I am thinking along the
lines of S4 methods with valid signatures.
Thanks aga
Sorry - you don't need to assign the value of initFields(). I was
going to do it in two lines but then realised one was enough... :)
TestClass <- setRefClass ("TestClass",
fields = list (text = "character"),
methods = list (
initialize = function (text) {
initFields(te
Hi Daniel,
I think you want to define an "initialize" method, as in
TestClass <- setRefClass ("TestClass",
fields = list (text = "character"),
methods = list (
initialize = function (text) { object <-
initFields(text=paste(text,"\n")) },
print = functio
Is it possible to override the $new(...) in the reference class
generator? I have tried adding a "new" method to the methods of the
class, but that is obviously not correct. I have also tried adding it to
the class generator, but the class generator still uses the default
constructor.
As a si
What you've written will certainly generate an infinite recursion. How
could it not?
Specifying an accessor function says to the system "Any reference to
this field should be evaluated by calling this function." But then you
refer to the field in the function itself, which will result in a c
On 23 October 2010 00:52, Jon Clayden wrote:
> On 22 October 2010 18:55, John Chambers wrote:
>
>>> As a suggestion, it would be nice if the accessors() method could be
>>> used to create just "getters" or just "setters" for particular fields,
>>> although I realise this can be worked around by r
On 22 October 2010 18:55, John Chambers wrote:
>> As a suggestion, it would be nice if the accessors() method could be
>> used to create just "getters" or just "setters" for particular fields,
>> although I realise this can be worked around by removing the unwanted
>> methods afterwards.
>
> In o
One correction:
On 10/22/10 10:55 AM, John Chambers wrote:
.
As a suggestion, it would be nice if the accessors() method could be
used to create just "getters" or just "setters" for particular fields,
although I realise this can be worked around by removing the unwanted
methods afterwards.
Last question first:
>
> More generally, I was wondering how firm the commitment is to
> providing this kind of programming mechanism. I know it's likely to
> change in some ways in future releases, but can I use it in packages,
> trusting that only a few tweaks will be needed for compatibility w
Dear all,
First, many thanks to John Chambers, and anyone else who was involved,
for the new support for "reference classes" in R 2.12.0. It's nice to
see this kind of functionality appear in a relatively R-like form, and
with the blessing of the core team. In some contexts it is undoubtedly
appea
64 matches
Mail list logo
