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
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
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 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
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 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
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
"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
> -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
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
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
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
44 matches
Mail list logo
