diff --git a/Doc/Manual/R.html b/Doc/Manual/R.html index 6547ab128..af9b48c89 100644 --- a/Doc/Manual/R.html +++ b/Doc/Manual/R.html @@ -17,6 +17,9 @@
The R bindings are under active development. They have been used to compile and run an R interface to QuantLib running on Mandriva Linux -with gcc. The R bindings also work on Microsoft Windows using Visual C++. +with gcc. They are also used to create the SimpleITK R package, which +runs on various linuxes and mac. Swig is used to create all wrapper +interfaces +to SimpleITK. The R +bindings also work on Microsoft Windows using Visual C++.
+There is no need to precompile large R files if the SWIG-generated code is being included +in an R package. The package infrastructure provides this service during package installation. +
-getitem and setitem use C++ conventions (i.e. zero based indices). [<- +getitem and setitem use C++ conventions (i.e. zero based indices). [<- and [ are overloaded to allow for R syntax (one based indices and slices)
@@ -182,14 +194,117 @@ slices)-C++ objects are implemented as external pointer objects with the class -being the mangled name of the class. The C++ classes are encapsulated -as an SEXP with an external pointer type. The class is the mangled -name of the class. The nice thing about R is that is allows you to -keep track of the pointer object which removes the necessity for a lot -of the proxy class baggage you see in other languages. +Wrapping of C++ classes for R works quite well. R has a special +type, known as an external reference, that can be used as a pointer +to arbitary things, including C++ classes. The proxy layers generated +for other classes are not required.
++ SWIG currently creates a custom hierarchy of R classes derived from the + external reference type and implements +type checking and function overloading in the R code it generates. In +the future we hope to utilise the built in R6 class structures. +
+ ++The R interface has the following capabilities: +
+class Vehicle {
+private:
+ int m_axles;
+public:
+ int Axles() {
+ return(m_axles);
+ }
+ bool Available;
+
+ Vehicle() {
+ Available=false;
+ m_axles=2;
+ }
+
+ Vehicle(int ax) {
+ Available=false;
+ m_axles=ax;
+ }
+};
+
++v1 <- Vehicle() +v2 <- Vehicle(4) +# access members +v1$Axles() +[1] 2 +v2$Axles +[1] 4 +v1$Available +[1] FALSE +# Set availabilty +v1$Available <- TRUE +v1$Available +[1] TRUE ++
+A useful trick to determine the methods that are available is to +query the R method definition as follows: +
+ +
+# display the methods for the class
+getMethod("$", class(v1))
+
+Method Definition:
+
+function (x, name)
+{
+ accessorFuns = list(Axles = Vehicle_Axles, Available = Vehicle_Available_get)
+ vaccessors = c("Available")
+ idx = pmatch(name, names(accessorFuns))
+ if (is.na(idx))
+ return(callNextMethod(x, name))
+ f = accessorFuns[[idx]]
+ if (is.na(match(name, vaccessors)))
+ function(...) {
+ f(x, ...)
+ }
+ else f(x)
+}
+
+
+Signatures:
+ x
+target "_p_Vehicle"
+defined "_p_Vehicle"
+
+
++The names in the accessorFuns list correspond to class methods while names in the vaccessors section +correspond to variables that may be modified. +