Re: [Rd] Reference classes

From: John Chambers <jmc_at_r-project.org>
Date: Fri, 22 Oct 2010 10:55:10 -0700

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 with
 > future versions of R, or is it possible that the whole infrastructure
 > will be removed in future?
 >

Speaking just for myself, I'd say it's pretty solid. Reasons:

Now as to what "tweaks" will be needed, that remains to be seen. But my guess is that most will be issues of implementation. The user interface is sufficiently standardized among languages that it has a reasonable chance to stay compatible.

Other comments below.

John

On 10/22/10 7:21 AM, Jon Clayden wrote:
> 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
> appealing to associate a set of methods with a class directly, rather
> than defining a load of generics which are only ever likely to be
> implemented for a single class, or some other such arrangement. (I was
> actually in the process of writing a package which did something
> similar to the reference class idea, although it is less fully
> realised.)
>
> My initial experiences with this functionality have been very
> positive. I've stumbled over one minor issue so far: default values of
> method parameters are not displayed by the help() method, viz.
>
>> library(methods)
>> Regex<- setRefClass("Regex", fields="string", methods=list(
> + isMatch = function (text, ignoreCase = FALSE)
> + {
> + 'Returns a logical vector of the same length as "text",
> indicating whether or not each element is a match to the regular
> expression.'
> + grepl(string, text, ignore.case=ignoreCase, perl=TRUE)
> + }
> + ))
>> Regex$help("isMatch")
> Call: $isMatch(text, ignoreCase = )
>
> Returns a logical vector of the same length as "text", indicating
> whether or not each element is a match to the regular expression.
>
> It seems unlikely that this is intentional, but correct me if I'm
> wrong. It still seems to happen with the latest R-patched (Mac OS X
> 10.5.8).

It's a bug.
>
> 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 other words, read-only fields. There is a facility for that implemented already, but it didn't yet make it into the documentation, and it could use some more testing. The generator object has a $lock() method that inserts a write-once type of method for one or more fields.   Example:

 > fg <- setRefClass("foo", list(bar = "numeric", flag = "character"),

+             methods = list(
+             addToBar = function(incr) {
+                 b = bar + incr
+                 bar <<- b
+                 b
+             }
+             ))
 > fg$lock("bar")

 > ff = new("foo", bar = 1.5)
 > ff$bar <- 2
Error in function (value) : Field "bar" is read-only

A revision will document this soon.

(And no, the workaround is not to remove methods. To customize access to a field, the technique is to write an accessor function for the field that, in this case, throws an error if it gets an argument. See the documentation for the fields argument. The convention here and the underlying mechanism are taken from active bindings for environments.)

>
> 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 with
> future versions of R, or is it possible that the whole infrastructure
> will be removed in future?
>
> All the best,
> Jon
>
> ______________________________________________
> R-devel_at_r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Fri 22 Oct 2010 - 18:00:27 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Sat 23 Oct 2010 - 04:10:12 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive