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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
