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:
- it's essentially an add-on and essentially all R code, so as long as
there is some interest, it's not hurting other code--it builds directly
on some valuable existing tools for environments, such as active bindings;
- this is something I've wanted to do for a while. The essential step
was being able to subclass environments, and that has been in place for
some time now;
- initial experience has been largely positive. The Rcpp package in
its newest version depends on reference classes.
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
>